La lista e' attiva

Francesco

Salve a tutti. Sto facendo una tesi su extremeprogramming e per
questo
sono interessato all'argomento.

Per ora sto lavorando sui test: abbiamo costruito un tool per
semplificare la costruzione di test con accesso ad un database.

Il mio tool e' costruito sopra OCUnit (SenTestingKit) tradotto dal
JUnit da Sente.

Sto lavorando con Objective C.

Sono curioso di vedere se questa mailing list riuscira' a diventare
interessante.

Marco Tamanti
presso ibn-i

Sono molto contento del tuo interesse per la lista.

"extremeprogramming-it" nasce dalla esplicita volonta' di Kent Beck di far sviluppare la comunita' XP in Italia.

Gli obiettivi che la lista si propone sono principalmente:
- Chiarire e diffondere i principi e le pratiche di XP.
- Aiutare ad applicare efficacemente XP.

Marco Tamanti wrote:

Salve a tutti. Sto facendo una tesi su extremeprogramming e per
questo sono interessato all'argomento.

- Qual e' l'obbiettivo della tesi,
- Come intendi raggiungerlo?
- _Come_ sei arrivato a XP?
- _Perche'_ hai scelto XP?

Sono curioso di vedere se questa mailing list riuscira' a diventare
interessante.

Nei prossimi giorni, il numero dei membri di questa lista e' destinato ad aumentare grazie all'interesse di persone che gia' hanno scelto di percorrere la strada di XP in Italia - con tutti i relativi vantaggi/problemi/dubbi.

Comunichiamo!

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418           http://www.sun.it/training/
=====================================================================
 

Salve a tutti,

Sono Hua. Mi occupo di sviluppo object-oriented in Java.

Ho cominciato a leggere il libro XP di Kent Beck. Vorrei applicare molte
delle sue idee concretamente. Spero che questa lista mi aiuti in questo.

Hua

--- In extremeprogramming-it@egroups.com, Francesco Cirillo
<fcirillo@a...> wrote:

...
> Molto interessante, ho alcune domande per te:
>
> - Qual e' l'obbiettivo della tesi,

Principalmente la mia tesi dovrebbe contenere una descrizione di XP e
delle sue tecniche. Inizialmente aggiungerò anche una breve
descrizione delle metodologie cosiddette heavy (pesanti) per esaltare
l'aspetto innovativo di XP.

> - Come intendi raggiungerlo?
> - _Come_ sei arrivato a XP?

La tesi la sto svolgendo presso la ditta IBN-Italy (http:\\www.ibn-
italy.com).
Stiamo assieme cercando di implementare XP nello sviluppo di software.
La sfida più grossa è riuscire ad introdurre XP in un progetto
già
avviato e funzionante, dove una parte considerevole di software è
già
stato scritto ed è attualmente utilizzato da utenti della stessa
IBN-
Italy. Quando sono arrivato avevano appena iniziato a scrivere i
primi test.

> - _Perche'_ hai scelto XP?

Mi è stato proposto da Giulio Cesare Solaroli, responsabile
sviluppo
software di IBN. Lui crede molto in XP e nelle sue potenzialità.

Ho letto "Extreme programming explained" di Kent Beck e ne sono
rimasto affascinato. Mi sono accorto che alcune tecniche le avevo
già
applicate assieme ad un mio amico durante lo sviluppo di un
interprete lisp ed uno prolog scritti in java.

Credo fermamente che XP possa aiutare gli sviluppatori di software.

Marco Tamanti
IBN-Italy

La quasi totalita' del materiale a proposito di XP
(extremeprogramming) e' in lingua inglese.

Da quando ho iniziato a scrivere la mia tesi su XP mi sono sorti vari
dubbi sulla terminologia da usare. I documenti da cui traggo le
informazioni sono tutte in lingua inglese, mentre la tesi e' in
Italiano.

Stesso "problema" mi pongo quando scrivo in questa mailing list.
Penso che questo sia il luogo giusto per definire un vocabolario
comune di termini da utilizzare per comprendersi a vicenda.

Sarebbe utile costruire assieme un piccolo dizionario di vocaboli
legati ad XP.
Per ogni vocabolo si puo' scegliere se usare l'originaria parola
inglese, oppure una delle possibili traduzioni in Italiano ed in tal
caso bisogna prendere la piu' significativa.
Se invece viene mantenuto il termine inglese non sarebbe male darne
una piccola traduzione per capirsi meglio.

Come punto di partenza avevo pensato di utilizzare un glossario sui
termini legati ad XP trovato tramite un link preso da:
http://users.vnet.net/wwake/
Purtroppo quando sono andato a ricercare tale documento non l'ho piu'
trovato.

Provo ad iniziare con i termini che mi vengono in mente, magari con
qualche esempio riesco a spiegarmi meglio.


Termine 		 Vocabolo suggerito  traduzione (ita-ing o viceversa)


Extreme programming  extreme programming  programmazione estrema
nome dato alla metodologia di sviluppo del software che e' al centro
di questa discussione; estrema perche' vuole portare all'estremo
l'utilizzo del senso comune.

Collective ownership  codice pubblico 	 proprieta' e responsabilita'
condivisa sul codice
ogni programmatore del team puo' intervenire su qualsiasi parte del
codice come se fosse stato lui a scriverlo la prima volta; i test
daranno poi il beneplacito.

Continuos integration  integrazione
il codice viene modificato in locale e dopo ogni piccola modifica
vengono eseguiti i test; se passano le modifiche vengono rese
visibili
a tutto il gruppo.

Customer 		 cliente (?!) 		 colui che commissiona il lavoro
credo che cliente sia un po' ambiguo, ma rende l'idea; penso che
customer possa essere interpretato correttamente in due diversi modi:
cliente (come utente finale) <---> datore o commissionatore di
lavoro,
visto come collega.

Feedback 		 feedback 		 retroazione
meccanismi che possono assicurare che lo sviluppo sta procedendo nel
verso giusto: test, release frequenti...

Metaphor 		 metafora 		 architettura
sostituisce il termine architettura per sottolineare che deve essere
facile da condividere, comunicare ed elaborare

Pair programming 	 programmazione in coppia
modalita' di sviluppare software in coppia: uno digita e l'altro
osserva e svolge un ruolo di controllore/suggeritore/stratega

Refactoring 		 ristrutturazione 	 ristrutturazione del software
modifica del software per renderlo piu' leggibile, modulare...

Scope 		 campo d'azione
quantita' di problemi che si intendono risolvere con la costruzione
del software

Simplicity 		 semplicita'
quando si costruisce il codice bisogna sempre pensare alla cosa piu'
semplice che funzioni; c'e' sempre la possibilita' di modificarla
successivamente

Small release 	 piccole (brevi) release  cicli di produzione brevi
i cicli di produzione devono essere corti, cosi' aumenta il feedback,
la flessibilita' ...

Team 			 gruppo 		 gruppo di sviluppatori

Testing 		 testing
si intende la costruzione e l'esecuzione di un insieme di test
automatici che vengono eseguiti ripetutamente, soprattutto durante le
fasi di integrazione


Mi scuso per l'incompletezza di questa tabella e per la confusione
che
potrebbero creare alcune spiegazioni che ho dato. Pero' se non
proviamo a costruirci un linguaggio comune le ambiguita' rimarrebbero
nascoste e la comprensione ne soffrirebbe.
Invito chiunque abbia altre idee...  voglia e pazienza di scrivere...
a farsi avanti e ad inserire nuovi vocaboli.
Se trovate definizioni migliori per i termini che ho sopra scritto,
ben vengano. Il mio e' solo un tentativo per sollevare il problema.
Fatemi sapere se e' una buona idea quella del vocabolario comune.

Marco Tamanti
ibn-italy

   Marco, quali pratiche XP avevi gia' avuto occasione di mettere in pratica?

Marco wrote:
"Principalmente la mia tesi dovrebbe contenere una descrizione di XP e delle sue tecniche."

   Penso ci siano diversi temi aperti che potresti affrontare:
    - La scalabilita' di XP. Puo' funzionare XP in un team di 100 persone? Come?
    - Quali sono i meccanismi economici/sociologici/tecnologici alla base dell'aumento di produttivita' promesso da XP.
    - Come applicare XP in progetti gia' iniziati (Oooops! ;->)?
    - Come insegnare XP?
    - Come si mappa XP rispetto a RUP?
(Se ti interessa approfondire uno di questi punti, non esitare!).

Marco wrote:
"Inizialmente aggiungerò anche una breve descrizione delle metodologie cosiddette heavy (pesanti) per esaltare l'aspetto innovativo di XP."

   Per questo potresti dare un'occhiata - se non l'hai gia' fatto - all'articolo di Bob Martin "Rupert and Ruphus" che puoi trovare nella sezione files di questo gruppo. (In realta' questa e' una lettura che consiglio a tutti, soprattutto ai manager.)
   Recentemente ho dovuto scrivere un Software Development Plan per un progetto americano dove si prevede l'uso di XP. "A lightweight process must not be intended in the sense that it neglects to draw up certain documentation. A lightweight process must be intended in the sense that, given equivalent results obtained, the process requires less effort in terms of the production of process artifacts. A lightweight process is a process which, ceteris paribus, uses up fewer resources. A lightweight process represents a situation of Paretian optimality." Ti/Vi piace questo modo di vedere la cosa?!
   Devo pero' essere chiaro, al momento la scalabilita' e' una dei punti critici di XP. E' difficile che team di 100 persone possano seguire un lightweight process come XP (o almeno, come dice Kent, nessuno lo ha mai fatto).  Occorre sicuramente un metodo meno light ;->. (Marco, se ti interessa questo punto vedi tra gli altri i lavori di Alistair Cockburn. Fondamentalmente lui classifica i metodi in famiglie rispetto a variabili quali project size, system criticality, priorities, fears. XP apparterrebbe alla famiglia Crystal (Clear) - Puoi cominciare dal suo sito http://members.aol.com/acockburn).

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418           http://www.sun.it/training/
=====================================================================
 

Marco wrote:
Mi è stato proposto da Giulio Cesare Solaroli, responsabile sviluppo software di IBN. Lui crede molto in XP e nelle sue potenzialità.
Stiamo assieme cercando di implementare XP nello sviluppo di software. La sfida più grossa è riuscire ad introdurre XP in un progetto già avviato e funzionante, dove una parte considerevole di software è già stato scritto ed è attualmente utilizzato da utenti della stessa IBN-Italy. Quando sono arrivato avevano appena iniziato a scrivere i primi test.

   Marco, penso sarebbe interessante che ci raccontassi quali pratiche XP usate e come. Sarebbe anche interessante che tu ci raccontassi come avete progressivamente introdotto quelle pratiche XP (Prima il testing, poi...).

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418           http://www.sun.it/training/
=====================================================================
 

La quasi totalita' del materiale a proposito di XP
(extremeprogramming) e' in lingua inglese.

Sarebbe utile costruire assieme un piccolo dizionario di vocaboli
legati ad XP.

Francesco

=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418         http://www.sun.it/training/
=====================================================================
 

Fatemi sapere se e' una buona idea quella del vocabolario comune.

Invito chiunque abbia altre idee...  voglia e pazienza di scrivere...
a farsi avanti e ad inserire nuovi vocaboli.

Per ogni vocabolo si puo' scegliere se usare l'originaria parola
inglese, oppure una delle possibili traduzioni in Italiano ed in tal
caso bisogna prendere la piu' significativa.

Se invece viene mantenuto il termine inglese non sarebbe male darne
una piccola traduzione per capirsi meglio.

Pero' se non
proviamo a costruirci un linguaggio comune le ambiguita' rimarrebbero
nascoste e la comprensione ne soffrirebbe.

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418      http://www.sun.it/training/
=====================================================================
 

Extreme programming             extreme programming             programmazione estrema
nome dato alla metodologia di sviluppo del software che e' al centro
di questa discussione; estrema perche' vuole portare all'estremo
l'utilizzo del senso comune.

Simplicity                              semplicita'
quando si costruisce il codice bisogna sempre pensare alla cosa piu'
semplice che funzioni; c'e' sempre la possibilita' di modificarla
successivamente

Small release                   piccole (brevi) release         cicli di produzione brevi
i cicli di produzione devono essere corti, cosi' aumenta il feedback,
la flessibilita' ...

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418         http://www.sun.it/training/
=====================================================================
 

--- In extremeprogramming-it@egroups.com, Francesco Cirillo
<fcirillo@a...> wrote:
> Marco wrote:
> "Ho letto 'Extreme programming explained' di Kent Beck e ne sono
rimasto
> affascinato. Mi sono accorto che alcune tecniche le avevo già
applicate
> assieme ad un mio amico durante lo sviluppo di un interprete lisp
ed
uno
> prolog scritti in java."
>
>    Marco, quali pratiche XP avevi gia' avuto occasione di mettere in
> pratica?
>

Innanzitutto eravamo in due, io e Francesco. Io avevo avuto piccole
esperienze di programmazione, mentre Francesco non era mai andato
oltre programmi quali il bubble sort scritto in c o pascal.
Insieme su questo progetto di interprete abbiamo lavorato per circa 5
mesi.

Abitiamo a circa mezz'ora di macchina, dunque qualche volta
lavoravamo
assieme e qualche volta ognuno a casa sua, tenendoci sempre in
stretto
contatto tramite e-mail e telefono.
Quando eravamo assieme applicavamo PAIR PROGRAMMING (senza nemmeno
sapere cosa fosse) esattamente nel modo descritto da Kent Beck. Forse
eravamo costretti dal fatto che sia a casa mia che a casa sua
avessimo
a disposizione un solo computer.
Quando eravamo ognuno a casa propria applicavamo un concetto di pair
programming che penso sia nuovo anche per XP: pair programming a
distanza. Esistono strumenti, quali l'instant message, che potrebbero
essere utilizzati per supportare pratiche del genere, ma per la mia
esperienza non li considero essenziali.
Appena una parte di codice veniva scritta da uno di noi due, veniva
subito inviata all'altro. Questo poi rileggeva il codice e lo
analizzava, eventualmente modificandolo e correggendolo.
Ci e' capitato parecchie volte che chi correggeva il codice trovasse
facilmente delle incongruenze o piccoli errori. Era come se uno
avesse
in mano la tastiera per scrivere codice e l'altro stesse osservando
lo
schermo ed allo stesso tempo avesse anche il tempo di ragionare ad un
piu' alto livello strategico. Capitava che questa seconda persona
semplicemente restituisse una e-mail con un elenco di dubbi che gli
si
presentavano.
L'overhead dovuto al controllo che la seconda persona faceva ci e'
stato ampiemente ripagato: abbiamo evitato diverse fasi di debugging
in cerca di errori e cosa fondamentale aumentava emormemente la
conoscenza del sistema da parte nostra.

All'inizio, per ogni classe che facevamo, aggiungevamo il metodo main
per poterla TESTARE. Appena eravamo sicuri che funzionasse
eliminavamo
il metodo main per lasciare solo quelli che ci servivano. Poi veniva
il momento di modificare il codice e la necessita' di testare
nuovamente. Veniva riaggiunto il metodo main che spesso conteneva lo
stessi identico codice scritto la settimana o il mese prima. Codice
che era stato cancellato e perso e dunque bisognava riscriverlo da
zero.
Dopo un paio di volte ci siamo fatti leggermente piu' furbi ed
abbiamo
deciso di lasciare i metodi main. Nella release finale del progetto
che abbiamo consegnato al professore sono ancora presenti tutti i
test. Anzi siamo riusciti a sfruttare questi metodi per aggiungere
nuove funzionalita' al nostro programma.
Faccio un esempio. Il nostro inteprete era stato pensato per avere
una
interfaccia windows. Alla fine, oltra all'interfaccia windows, il
nostro programma poteva essere utilizzato anche da riga di comando e
sfruttava la shell di DOS. Questo e' stato fatto senza nessuno sforzo
riutilizzando i metodi main che usavamo per provare come funzionavano
i due interpreti lisp e prolog che stavamo costruendo. Poiche' java
e'
notoriamente carente in fatto di prestazioni sull'interfaccia
grafica,
risulta molto piu' comodo utilizzare i nostri interpreti sfruttando
il
DOS e solo cosi' possono esserne messe in evidenza le potenzialita'
ed
i limiti.
Quando trovavamo una frase che il nostro riconoscitore non
interpretava bene, la aggiungevamo al metodo main e successivamente
correggevamo l'errore.
Alla fine avevamo tanti piccoli test che ci assicuravano che i nostri
interpreti funzionassero correttamente anche dopo modifiche
sostanziali. L'unica pecca era che i nostri test non erano automatici
Per quanto riguarda il REFACTORING, ci e' venuto naturale. Io sono
pignolo e mi piacciono le cose fatte bene. Anche Francesco un po' lo
e' e si e' fatto facilmete influenzare. Non esiste una parte del
nostro codice che non sia stata modificata almeno due o tre volte.
Molte modifiche erano semplici e servivano solo per rendere il codice
piu' comprensibile (AUTOESPLICATIVO direbbe XP), altre comprendevano
parti ampie di codice ed erano funzionali.
Abbiamo per esempio riscritto da zero il parser prolog quando ci
siamo
accorti che il nostro non ripecchiava le specifiche prolog con le sue
precedenze degli operatori definite nel range 1-1200 e le varie
regole
di associativita' per operatori unari e binari.
Sul primo parser avevamo lavorato parecchio, soprattutto per cercare
di ovviare all'inerente complessita' ed ambiguita' della sintassi
prolog. Ci sembrava che riscrivere il parser fosse come ripartire da
capo. Abbiamo poi deciso che non costava molto provare a fare un
nuovo
parser e finche' non avrebbe funzionato potevamo tenerci quello
vecchio. Se il nuovo codice scritto non avrebbe dato subito dei
risultati sarebbe stato subito abbandonato. E' stata una scommessa
che
ha richesto parecchio CORAGGIO, ma alla fine e' stata vinta.
Nel nostro release finale entrambi i parser funzionano correttamente,
anche se il secondo ha molte piu' funzionalita'.
Altro caso analogo e' stato quando ho deciso di riscrivere da capo
l'unificatore prolog quando mi sono accorto che quello che avevamo
era
altamente inefficiente e praticamente illeggibile (arrivava a 6
livelli di if innestati).

Il fatto di lavorare a distanza, spesso sulle stesse parti di codice,
implicava una una rigida politica di INTEGRAZIONE delle varie parti.
Ogni vota che ognuno di noi faceva una modifica che riteneva
sostanziale e che avrebbe potuto influenzare il lavoro dell'altro si
procedeva ad integrare tramite strumenti per il confronto dei file.
Piu' di rado si facevano controlli sui vari file per integrare anche
le piccole modifiche. Ci e' capitato anche di avere fatto la stessa
modifica o di aver corretto lo stesso errore contemporaneamente,
ignari di cosa stesse facendo l'altro.

Sul tavolo avevo sempre un foglio di carta in cui annotavo tutte i
lavori da fare (TO DO) successivamente che mi venivano in mente
mentre
scrivevo il codice. Dalla lista sceglievo poi sempre il piu'
importante e quello che avesse PIU' SENSO FARE. Anche ad interprete
ultimato la lista non era ancora vuota, ma le cose rimaste erano di
poco conto, oppure erano state rese inutili da cambiamenti di rotta.

Ora non mi vengono in mente altre analogie con XP, ma sono sicuro che
ce ne sono altre. Mentre leggevo il libro di Kent Beck spesso mi
sorprendevo scoprendo quante volte dicevo a me stesso "questo l'ho
gia' provato". Forse e' proprio questa la ragione per cui XP mi ha
subito affascinato. XP comprende ed organizza nel migliore dei modi
un
insieme di tecniche che derivano dalle buone abitudini prese da chi
si
deve scontrare quotadianamente con la stesura di programmi. Non c'e'
niente di artificiosi e quasi tutto deriva dal buon senso comune.

Un'ultima cosa che voglio sottolineare e' che scrivere il codice per
i
due interpreti e' stato divertente. Siamo stati entrambi soddisfatti
del lavoro svolto ed abbiamo condiviso la gioia e la consapevolezza
di
aver costruito software di alta qualita'. Idee su come proseguire e
migliorare il nostro progetto ne avevamo tantissime (il giorno dopo
l'esame, in un pomeriggio siamo riuscitia ad introdurre la tail
recursion per l'interprete lisp) ed ogni parte del nostro codice e'
pronto a richiedere ulterior

Abitiamo a circa mezz'ora di macchina, dunque qualche volta
lavoravamo assieme e qualche volta ognuno a casa sua, tenendoci sempre in
stretto contatto tramite e-mail e telefono.
Quando eravamo assieme applicavamo PAIR PROGRAMMING (senza nemmeno
sapere cosa fosse) esattamente nel modo descritto da Kent Beck.

Quando eravamo ognuno a casa propria applicavamo un concetto di pair
programming che penso sia nuovo anche per XP: pair programming a
distanza. Esistono strumenti, quali l'instant message, che potrebbero
essere utilizzati per supportare pratiche del genere, ma per la mia
esperienza non li considero essenziali.
Appena una parte di codice veniva scritta da uno di noi due, veniva
subito inviata all'altro. Questo poi rileggeva il codice e lo
analizzava, eventualmente modificandolo e correggendolo.
Ci e' capitato parecchie volte che chi correggeva il codice trovasse
facilmente delle incongruenze o piccoli errori. Era come se uno
avesse in mano la tastiera per scrivere codice e l'altro stesse osservando
lo schermo ed allo stesso tempo avesse anche il tempo di ragionare ad un
piu' alto livello strategico. Capitava che questa seconda persona
semplicemente restituisse una e-mail con un elenco di dubbi che gli
si presentavano. L'overhead dovuto al controllo che la seconda persona faceva ci e' stato ampiemente ripagato: abbiamo evitato diverse fasi di debugging in cerca di errori e cosa fondamentale aumentava emormemente la conoscenza del sistema da parte nostra.

All'inizio, per ogni classe che facevamo, aggiungevamo il metodo main
per poterla TESTARE. Appena eravamo sicuri che funzionasse
eliminavamo il metodo main per lasciare solo quelli che ci servivano. Poi veniva il momento di modificare il codice e la necessita' di testare
nuovamente. Veniva riaggiunto il metodo main che spesso conteneva lo
stessi identico codice scritto la settimana o il mese prima. Codice
che era stato cancellato e perso e dunque bisognava riscriverlo da
zero. Dopo un paio di volte ci siamo fatti leggermente piu' furbi ed
abbiamo deciso di lasciare i metodi main. Nella release finale del progetto
che abbiamo consegnato al professore sono ancora presenti tutti i
test. Anzi siamo riusciti a sfruttare questi metodi per aggiungere
nuove funzionalita' al nostro programma.
Faccio un esempio. Il nostro inteprete era stato pensato per avere
una interfaccia windows. Alla fine, oltra all'interfaccia windows, il
nostro programma poteva essere utilizzato anche da riga di comando e
sfruttava la shell di DOS. Questo e' stato fatto senza nessuno sforzo
riutilizzando i metodi main che usavamo per provare come funzionavano
i due interpreti lisp e prolog che stavamo costruendo. Poiche' java
e' notoriamente carente in fatto di prestazioni sull'interfaccia
grafica, risulta molto piu' comodo utilizzare i nostri interpreti sfruttando
il DOS e solo cosi' possono esserne messe in evidenza le potenzialita'
ed i limiti.

Quando trovavamo una frase che il nostro riconoscitore non
interpretava bene, la aggiungevamo al metodo main e successivamente
correggevamo l'errore.

Per quanto riguarda il REFACTORING, ci e' venuto naturale. Io sono
pignolo e mi piacciono le cose fatte bene. Anche Francesco un po' lo
e' e si e' fatto facilmete influenzare. Non esiste una parte del
nostro codice che non sia stata modificata almeno due o tre volte.

Membri della lista, cosa ne pensate voi?

Molte modifiche erano semplici e servivano solo per rendere il codice
piu' comprensibile (AUTOESPLICATIVO direbbe XP

), altre comprendevano parti ampie di codice ed erano funzionali.
Abbiamo per esempio riscritto da zero il parser prolog quando ci
siamo accorti che il nostro non ripecchiava le specifiche prolog con le sue
precedenze degli operatori definite nel range 1-1200 e le varie
regole di associativita' per operatori unari e binari.
Sul primo parser avevamo lavorato parecchio, soprattutto per cercare
di ovviare all'inerente complessita' ed ambiguita' della sintassi
prolog. Ci sembrava che riscrivere il parser fosse come ripartire da
capo. Abbiamo poi deciso che non costava molto provare a fare un
nuovo parser e finche' non avrebbe funzionato potevamo tenerci quello
vecchio. Se il nuovo codice scritto non avrebbe dato subito dei
risultati sarebbe stato subito abbandonato. E' stata una scommessa
che ha richesto parecchio CORAGGIO, ma alla fine e' stata vinta.
Nel nostro release finale entrambi i parser funzionano correttamente,
anche se il secondo ha molte piu' funzionalita'.

Il fatto di lavorare a distanza, spesso sulle stesse parti di codice,
implicava una una rigida politica di INTEGRAZIONE delle varie parti.
Ogni vota che ognuno di noi faceva una modifica che riteneva
sostanziale e che avrebbe potuto influenzare il lavoro dell'altro si
procedeva ad integrare tramite strumenti per il confronto dei file.

Piu' di rado si facevano controlli sui vari file per integrare anche
le piccole modifiche.

Ci e' capitato anche di avere fatto la stessa
modifica o di aver corretto lo stesso errore contemporaneamente,
ignari di cosa stesse facendo l'altro.

Sul tavolo avevo sempre un foglio di carta in cui annotavo tutte i
lavori da fare (TO DO) successivamente che mi venivano in mente
mentre scrivevo il codice.

Dalla lista sceglievo poi sempre il piu'
importante e quello che avesse PIU' SENSO FARE. Anche ad interprete
ultimato la lista non era ancora vuota, ma le cose rimaste erano di
poco conto, oppure erano state rese inutili da cambiamenti di rotta.

Un'ultima cosa che voglio sottolineare e' che scrivere il codice per
i due interpreti e' stato divertente. Siamo stati entrambi soddisfatti
del lavoro svolto ed abbiamo condiviso la gioia e la consapevolezza
di aver costruito software di alta qualita'. Idee su come proseguire e
migliorare il nostro progetto ne avevamo tantissime (il giorno dopo
l'esame, in un pomeriggio siamo riuscitia ad introdurre la tail
recursion per l'interprete lisp) ed ogni parte del nostro codice e'
pronto a richiedere ulterior

Mentre leggevo il libro di Kent Beck spesso mi
sorprendevo scoprendo quante volte dicevo a me stesso "questo l'ho
gia' provato".

So che diversi dei membri di questa lista stanno leggendo il libro di Kent. Sono convinto che anche voi troverete dei deja vu, delle pratiche gia' provate. Mi piacerebbe che le raccontaste.

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418         http://www.sun.it/training/
=====================================================================
 

OK per tutti?

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418            http://www.sun.it/training/
=====================================================================
 

Io ci sarò, domani, sabato 14 ottobre ore 21:00.

Ciao a tutti!
Giuliano

--- In extremeprogramming-it@egroups.com, Francesco Cirillo
<fcirillo@a...> wrote:
> Prima chat del gruppo extremeprogramming-it sabato 14 ottobre ore
21:00.
>
> OK per tutti?
>
> Francesco
>
> --
>
=====================================================================
> Francesco Cirillo                                  <fcirillo@a...>
> --------------------------------------------------------------------
-
>   Object Mentor                       Training courses offered:
>   Financial Software Engineering        -Object Oriented Analysis
>   Design Consulting                      and Design with UML
>   Sun Microsystems Instructor           -Java and CORBA: Building
>   Sun Certified Java Programmer          Applications with OrbixWeb
>   voice:  +39 0761 659.019              -Java Architecture Planning
>   fax:    +39 0761 659.019               and Design
>   mobile: +39 0338 8527418            http://www.sun.it/training/
>
=====================================================================

Ore 20:58
Siamo in chat
http://www.egroups.com/chat/extremeprogramming-it
Se avete problemi mandatemi una email
fcirillo@...

Francesco

Salve a tutti,
ciao Giuliano,
Il mio feedback e' molto semplice e chiaro: molto molto interessante!
Non avevo mai partecipato ad una chat, ma, soprattutto grazie
all'aiuto di Francesco, non e' stato difficile interagire.
E' stata un'esperienza importante. Esiste la concreta possibilita' di
condividere esperienze di lavoro. Non vedo punti negativi, se non il
fatto di essere stati costretti a riconnetterci varie volte causa
traffico.

Entro mercoledi' mandero' l'email con l'agenda.
A sabato prossimo alle 14:00

Maria

Ciao a tutti,

mi chiamo Giuliano e sono il responsabile di un gruppo di sviluppo in Banca
IMI. Facciamo applicazioni in Java per prodotti finanziari di tipo B2C e
B2B. Conosco Francesco Cirillo da febbraio, quando ha iniziato un'attività
di mentoring in Banca IMI che potrebbe portarci (ce lo auguriamo tutti) a
operare attraverso diverse pratiche di XP.

Ok, sbrigate le formalità di presentazione, volevo darvi anch'io un po' di
feedback sulla prima chat che si è svolta la sera di sabato 14 alle 21:00.
Erano online Francesco, Hua, Maria e il sottoscritto.

Abbiamo parlato in ordine sparso di pomodoro, carte, testing prima del
codice, Tracking & Planning, tempi x l'introduzione di pratiche XP, linee
guida x l'assunzione di nuove risorse in un gruppo XP. In ultimo abbiamo
sfiorato WIKI, lasciato da parte x mancanza di tempo.

Su richiesta di Francesco vi do qualche impressione.
Cosa mi è piaciuto: notevole la possibilità di scambiarci esperienze in
diretta, non mediate da mail meditabonde; sono emerse alcune cosucce sul
T&P veramente interessanti. Maria ha posto qualche domanda importante a cui
ho tentato di rispondere in modo effettivo, e questo processo di scambio di
idee è estremamente produttivo x entrambe le parti.

Cosa non mi è piaciuto: la chat su egroups è pessima a quell'ora, dobbiamo
trovare un modo x renderla + veloce (infatti se non sbaglio c'è una
proposta per le 14:00, a quell'ora gli americani dormono e dovrebbe andare
meglio). Non avevamo un'agenda preparata, x cui abbiamo proceduto in modo
un po' confuso, è importante preparare sempre un'agenda con un moderatore
(Francesco) che la gestisca.

HTH
Ciao, Giuliano

PS: alcune delle cose che ho citato possono non essere note ai
partecipanti. Vi prego di segnalarmelo e pubblicherò una brevissima
descrizione x ciascuna, sempre se Francesco è d'accordo.



|--------+----------------------->
|        |          sakun_srl@hot|
|        |          mail.com     |
|        |                       |
|        |          10/15/00     |
|        |          08:50 AM     |
|        |          Please       |
|        |          respond to   |
|        |          extremeprogra|
|        |          mming-it     |
|        |                       |
|--------+----------------------->
   >-----------------------------------------------------------------------|
   |                                                                       |
   |       To:     extremeprogramming-it@egroups.com                       |
   |       cc:     (bcc: Piergiuliano Bossi/MI/IMISIGECOSIM)               |
   |       Subject:     [xp-it] Feedback prima chat                        |
   >-----------------------------------------------------------------------|

Salve a tutti,
ciao Giuliano,
Il mio feedback e' molto semplice e chiaro: molto molto interessante!
Non avevo mai partecipato ad una chat, ma, soprattutto grazie
all'aiuto di Francesco, non e' stato difficile interagire.
E' stata un'esperienza importante. Esiste la concreta possibilita' di
condividere esperienze di lavoro. Non vedo punti negativi, se non il
fatto di essere stati costretti a riconnetterci varie volte causa
traffico.

Entro mercoledi' mandero' l'email con l'agenda.
A sabato prossimo alle 14:00

Maria





To unsubscribe from this group, send an email to:
extremeprogramming-it-unsubscribe@egroups.com

Mi sembra che Giuliano abbia riassunto brillantemente i contenuti
della chat.

Personalmente considero l'esperienza molto interessante soprattutto
perche' si sono affrontati argomenti *reali* relativamente a XP.

Sono d'accordo con Giuliano sulla necessita' di avere un'agenda. Come
gia' detto in chat sarebbe bene che entro il mercoledi' proponessimo
gli argomenti per la chat del sabato. L'agenda dovra' essere pronta
entro venerdi' (saranno preferiti i dubbi).

Giuliano:
"PS: alcune delle cose che ho citato possono non essere note ai
partecipanti. Vi prego di segnalarmelo e pubblicherò una brevissima
descrizione x ciascuna, sempre se Francesco è d'accordo."
Per me va benissimo.

Quanto al log della chat, mi sembra che su egroups non sia
disponibile
questa facility. Ho mandato una email ai gestori del servizio.
Aspettiamo.

La prossima chat e' programmata per sabato 21, ore 14:00.

Francesco

Alcune delle cose che abbiamo affrontato durante la chat (sarò impreciso
naturalmente, ma auspico che siate in grado di correggermi se necessario).

**Pomodoro**
Un pomodoro è un'unità temporale di 30 minuti [x una descrizione
dell'origine del concetto vi rimando a Francesco, dopotutto il pomodoro è
farina del suo sacco :)]. In sintesi:
*) l'attività del giorno viene suddivisa in quanti da 30 minuti;
*) ogni quanto è dedicato a una e una sola attività;
*) lo scadere del quanto viene gestito da una sveglia (sono perfetti i
timer da cucina o simili, qui in Banca IMI ce lo siamo fatti naturalmente
in Java);
*) al termine di ogni quanto bisognerebbe riposarsi 5', liberare un poco la
mente x poter ricominciare;
*) mano a mano che la giornata procede ogni quanto viene tracciato su carta
con l'attività svolta.
Ciò consente di incrementare notevolmente la produttività, grazie a una
miglior pianificazione e focalizzazione sulle attività importanti. Inoltre,
forse ancora + importante è la possibilità di tracciare, misurare le
attività, implementando delle metriche, ottenendo feedback dalle proprie
giornate lavorative.
Una delle cose più strane che mi è successa usando i pomodori è stato
rendermi conto che, nonostante stessi al lavoro 12h, magari saltando anche
il pranzo, in realtà racimolavo al termine della giornata non più di 14 o
15 pomodori, a volte anche meno. Questo è un chiaro segnale che c'è
qualcosa che non va, che bisogna migliorare la produttività sia per
l'azienda che per la propria salute mentale.

**T&P**
Il foglio di Tracking & Planning è un foglio excel che consente di
pianificare, tracciare, misurare, analizzare l'attività relativa a un
progetto, una risorsa, ecc.
Francesco direbbe che è molto più di tutto ciò, è una contabilità in
partita doppia! Di  fatto è uno strumento molto utile, soprattutto se usato
in congiunzione con il pomodoro, perchè offre la possibilità di gestire un
progetto e/o le risorse in modo effettivo, ben diverso dall'approccio
direttivo tipico di una classica gestione di progetto (oserei dire Gannt
oriented). E' composto da 2 parti, una in cui si inseriscono elementi
(nuovi task con la loro previsione, nuove stime, aggironamenti delle
quantità effettivamente lavorate, completamento di task aperti) e una in
cui si effettuano le query sulla parte precedente, con rendicontazione dei
tempi stimati rispetto a quelli realmente consumati, ecc.

**Carta**
Credo che sia uno dei concetti + famosi di XP, e in fondo anche quello
apparentemente + semplice. Le carte sono dei talloncini di carta (per
l'appunto!) di circa 15x10 cm., sui quali il team scrive le necessità del
committente. Le carte consentono di scremare il racconto dell'utente
individuano in modo il più coeso possibile i suoi bisogni. Non solo,
costituiscono un vocabolario comune su cui il committente e il team devono
convenire. Dal punto di vista del committente, le carte consentono di
schedulare assieme al coach un piano di attacco e una consegna, partendo
dalle stime fatte dal team e riportate sulla carta. All'interno del team,
le carte consentono di fare schizzi di diagrammi, scrivere annotazioni,
task da eseguire, ecc. Le carte costituiscono la documentazione di analisi
e di design (codice a parte). Il processo diventa leggero, probabilmente un
po' più deformalizzato, ma non per questo meno ricco di informazioni. Il
controllo aumenta, perchè lo scambio di informazioni è più semplice e
quindi più efficace. In ultimo, le carte vengono prese in carico dagli
sviluppatori in modo proattivo (ie: il coach chiede: "chi vuole occuparsi
della finestra  di login?", gli sviluppatori Roberto e Alberto si
propongono, alla fine uno dei due affronta il problema, magari in
pair-programming con il secondo), scatenando delle dinamiche mentali molto
produttive per il progetto e x il team. XP è fatto di coraggio ... :)

Ciao, Giuliano



|--------+----------------------->
|        |          fcirillo@acm.|
|        |          org          |
|        |                       |
|        |          10/16/00     |
|        |          10:02 AM     |
|        |          Please       |
|        |          respond to   |
|        |          extremeprogra|
|        |          mming-it     |
|        |                       |
|--------+----------------------->
   >-----------------------------------------------------------------------|
   |                                                                       |
   |       To:     extremeprogramming-it@egroups.com                       |
   |       cc:     (bcc: Piergiuliano Bossi/MI/IMISIGECOSIM)               |
   |       Subject:     [xp-it] Feedback Prima Chat                        |
   >-----------------------------------------------------------------------|






Mi sembra che Giuliano abbia riassunto brillantemente i contenuti
della chat.

Personalmente considero l'esperienza molto interessante soprattutto
perche' si sono affrontati argomenti *reali* relativamente a XP.

Sono d'accordo con Giuliano sulla necessita' di avere un'agenda. Come
gia' detto in chat sarebbe bene che entro il mercoledi' proponessimo
gli argomenti per la chat del sabato. L'agenda dovra' essere pronta
entro venerdi' (saranno preferiti i dubbi).

Giuliano:
"PS: alcune delle cose che ho citato possono non essere note ai
partecipanti. Vi prego di segnalarmelo e pubblicherò una brevissima
descrizione x ciascuna, sempre se Francesco è d'accordo."
Per me va benissimo.

Quanto al log della chat, mi sembra che su egroups non sia
disponibile
questa facility. Ho mandato una email ai gestori del servizio.
Aspettiamo.

La prossima chat e' programmata per sabato 21, ore 14:00.

Francesco



To unsubscribe from this group, send an email to:
extremeprogramming-it-unsubscribe@egroups.com

Siamo nuovamente in chat, sono le 14:28, e ci rimarremo di sicuro
fino alle 15.
http://www.egroups.com/chat/extremeprogramming-it

Spero di incontrarvi...
Giuliano

Purtroppo Paola, Gianfranco ed io non riusciamo ad entrare da diverse parti
di Italia.

Se sei li' con qualcuno fai tu da moderatore Giuliano.

Io riprovo fino alle 15.00

Francesco

pbossi@... wrote:

> Siamo nuovamente in chat, sono le 14:28, e ci rimarremo di sicuro
> fino alle 15.
> http://www.egroups.com/chat/extremeprogramming-it
>
> Spero di incontrarvi...
> Giuliano
>
>
> To unsubscribe from this group, send an email to:
> extremeprogramming-it-unsubscribe@egroups.com

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
   Object Mentor                       Training courses offered:
   Financial Software Engineering        -Object Oriented Analysis
   Design Consulting                      and Design with UML
   Sun Microsystems Instructor           -Java and CORBA: Building
   Sun Certified Java Programmer          Applications with OrbixWeb
   voice:  +39 0761 659.019              -Java Architecture Planning
   fax:    +39 0761 659.019               and Design
   mobile: +39 0338 8527418            http://www.sun.it/training/
=====================================================================

Ciao,

sabato 28 alle 14:00 c'è stata un'altra chat. Presenti: il sottoscritto,
Francesco Cirillo, Hua, Paola Turci.

Abbiamo parlato di:
- WIKI
- Test-first / Design by testing
In modo sintetico entrambi gli argomenti sono stati molto interessanti,
anche se il secondo necessita sicuramente di maggior approfondimento.

**WIKI**
WIKI (http://c2.com/cgi/wiki) è un database, un generatore di ipertesti.
Dice Francesco che l'intento di WIKI era potere evitare di scrivere
foglietti volanti e invece organizzarli in modo ipertestuale; da lì si è
notato che il sistema di informazioni poteva crescere non aumentando la
complessità. Tutto si basa su coesione e coupling (nel senso che ogni
pagina deve essere coesa con il suo titolo) ed è rifattorizzabile.
Come dicono gli stessi autori (Cunningham): "Wiki is a composition system;
it's a discussion medium; it's a repository; it's a mail system; it's a
tool for collaboration. Really, we don't know quite what it is, but it's a
fun way of communicating asynchronously across the network"
Giuliano chiede: dato che tutti possono fare qualunque intervento
liberamente, che cosa impedisce alle informazioni contenute in un sistema
wiki-like di deteriorarsi?
Francesco risponde: è possibile applicare password.
Paola osserva che non è il sistema che garantisce la coesione e Francesco
afferma che non è il sistema a fare queste cose, ma la testa! Ogni volta
che 1 pagina presenta degli accoppiamenti o argomenti scarsamente coesi con
il titolo della pagina è possibile rifattorizzare, reificare, creare una
nuova pagina. Paola osserva che il sistema stesso supporta questo genere di
meccanismo.
Giuliano è d'accordo, ma è perplesso sulla sua applicazione tra persone non
disciplinate.
Paola dice che Giuliano ha ragione, Francesco dice che bisogna imparare.
Giuliano chiede se WIKI su web funzioni: Francesco afferma che WIKI è un
ottimo repository di informazioni, residuale rispetto alla soluzione del
publisher e del web editing, ma comunque effettivamente utile, le cose sul
WIKI si trovano. Alcune perplessità sorgono sul *rendering* del tutto, ma
si può migliorare.
Giuliano afferma che dopotutto si tratti di una riedizione dell'idea che è
alla base stessa dei newsgroups, con la differenza che questi ultimi sono
gruppi di *discussione*, mentre probabilmente WIKI ha la pretesa di
rappresentare una fotografia statica di informazione dinamicamente in
movimento. Probabilmente WIKI è il modo migliore di organizzare la
conoscenza in un gruppo di persone che hanno già qualcosa che le accomuna
fortemente (ciò favorisce in modo implicito la coesione). Sicuramente è
possibile fare degli esperimenti per organizzare su un sistema wiki-like la
conoscenza propria di un gruppo di lavoro (gli handbook).
Francesco è d'accordo, l'idea che le informazioni possano organizzarsi
"spontaneamente" conoscendo i semplici principi di coesione e coupling è
buona. C'è un gruppo di lavoro in Svizzera che usa wiki per il project
management. Francesco comincerebbe da lì.

**Test-first / Design by testing**
Giuliano esordisce affermando la propria professione di fede nei confronti
dell'inversione del microciclo. Traducendo la in codice la storia
corrispondente al test si fa un primo design "maialino" dal quale partire e
che costituisce il nocciolo attorno a cui poi si costruisce il codice che
dà il valore al committente. Giuliano pensa anche che senza il refactoring
è assolutamente inutile il design by testing: design by testing e
refactoring sono intimamente collegati.
Francesco è d'accordo, anche se sul fatto che il testing costituisca un
primo design "maialino" ha qualche dubbio: pensa che attraverso il testing
si sia portati a produrre un design molto semplice e molto comprensibile,
in altre parole poco cervellotico.
Paola aggiunge: anche non ambiguo.
Francesco concorda: il testing produce un design di livello alto e non
ambiguo.
Giuliano si ritrova nella parole di Paola e Francesco ma si chiede anche
come è possibile produrre design di alto livello e non ambiguo senza
anticipare?
Francesco brevemente: seguendo quello che dice il cliente!
Giuliano: dove la porzione di business logic nascosta dietro alle
interazioni UI molto semplice è smisurata (comprendendo anche collegamenti
a sistemi di interconnessione complessi, transazioni distribuite su sistemi
di terze parti, ecc.), in questo caso non c'è troppa logica dietro a un
test? Non si corre il rischio di essere sopraffatti dalla complessità?
Paola dice: devi sempre considerare il fatto di partire da un test minimo e
poi farlo crescere.
Giuliano pone l'ultima domanda, che rimane sospesa per la prossima chat:
viceversa, è possibile scrivere anche in modo classico buoni test, che
valutano bene il funzionamento dei meccanismi sottostanti a un sistema,
mentre poi le GUI sono ignorate o non adeguatamente testate (e questo fa
imbestialire il committente); allora, non è forse necessario avere sistemi
che testino anche i meccanismi intrinseci delle GUI?
Per Francesco, comunque, il vero problema sta nella definizione di un buon
ambiente per il testing.

In agenda per il prossimo appuntamento:
- approfondimento tematiche di Test-first / Design by testing
- refactoring

Sabato 4 novembre io non ci sarò, se terrete comunque la chat vi prego di
diffondere al termine un report come questo.
Ciao e grazie, Giuliano



Piergiuliano Bossi
Information Technology  -
Banca IMI - Milan
--
This message is confidential and solely for the intended addressee(s). If
you are not the intended recipient of this message, please notify the
sender immediately and delete it from your system. Unauthorised
reproduction, disclosure, modification and/or distribution of this e-mail
is strictly prohibited. The contents of this e-mail do not constitute a
commitment by Banca d'Intermediazione Mobiliare IMI S.p.A. (Banca IMI),
except where expressly provided for in a written agreement between you and
Banca IMI.

Banca d?Intermediazione Mobiliare IMI S.p.A. is an authorised Bank in
Italy.
Banca d?Intermediazione Mobiliare IMI S.p.A., London Branch, a member of
the London Stock Exchange,
is regulated by the Securities and Futures Authority for the conduct of
investment business in the UK.

Ciao A Tutti,
  Mi chiamo Davide, sono uno sviluppatore Java, mi interesso di OO
annessi e connessi. Ieri qualcuno :-) mi ha detto che esisteva questa
mlist ed allora eccomi qui.
Alcuni amici mi chiamano "trivella" perche' ho l'abitudine di
trivellare in internet alla ricerca di info su cio' che mi piace,
bene se andate nella sezione link vedrete cio' che ho trovato (se vi
puo' essere utile). Avrei anche riportato gli indirizzi qui sotto, ma
ho paura che qui qualcuno mi bacchetti sull'"once and only once" :-
))  quindi....

bye, Alla prossima,
  Davide

 Mi chiamo Davide, sono uno sviluppatore Java, mi interesso di OO
annessi e connessi. Ieri qualcuno :-) mi ha detto che esisteva questa
mlist ed allora eccomi qui.

Approfitto per comunicare che domani avra' luogo alle 14:00 la chat settimanale.

Anche questa volta non abbiamo un'agenda, ma so che Giuliano ha diversi argomenti *caldi*.

Francesco

--
=====================================================================
Francesco Cirillo                                  <fcirillo@...>
---------------------------------------------------------------------
  Object Mentor                       Training courses offered:
  Financial Software Engineering        -Object Oriented Analysis
  Design Consulting                      and Design with UML
  Sun Microsystems Instructor           -Java and CORBA: Building
  Sun Certified Java Programmer          Applications with OrbixWeb
  voice:  +39 0761 659.019              -Java Architecture Planning
  fax:    +39 0761 659.019               and Design
  mobile: +39 0338 8527418            http://www.sun.it/training/
=====================================================================
 

Hello Italy!

My name is Alex Viggio and I started an XP group for the Colorado
Front Range. We have 100+ members from Fort Collins, Boulder, Denver,
and Colorado Springs. I just wanted to extend the welcome for any of
you who might be in our area (skiing anyone?), and might be
interested in meeting local XP'ers.

Our website is at www.xpdenver.org and we also have monthly meetings
and an eGroups mailing list. I think it would be cool for all of the
XP groups around the States to link up.

Best Regards,
- Alex

aviggio@...

www.xpdenver.org

Francesco e' in viaggio.
Non riesce a venire per le 2.
Ho parlato lui dice se Giuliano fa il moderatore.
Giuliano decide se fare la chat.
OK?

Hua

Io ci sono, mi sono appena collegato ... se siete d'accordo diamoci
un pomodoro sul refactoring, bello denso, altrimenti rimandiamo a
sabato prox.

Ciao, Giuliano

--- In extremeprogramming-it@egroups.com, "Meihua Su" <hua@l...>
wrote:
> Francesco e' in viaggio.
> Non riesce a venire per le 2.
> Ho parlato lui dice se Giuliano fa il moderatore.
> Giuliano decide se fare la chat.
> OK?
>
> Hua

Ciao a tutti,

vi allego un log della chat del 02-12-00. Presenti:
*) Francesco Cirillo
*) Davide Varvello
*) il sottoscritto

****************CUT HERE****************
fcirillo: vorrei che ognuno di noi proponesse due/tre argomenti per la
chat di oggi|
pbossi: 1) refactoring - 2) test-first - 3) integrazione
fcirillo: davide?!|
varvello: 1) Slices in iterative incremental development 2)
integrazione waterfall e IID
varvello: |
pbossi: comunque se stavate già parlando di qualcosa non vi
preoccupate, non vi volevo
    interrompere
pbossi: |
fcirillo: io direi di partire con slice e iid e passare a
refactoring/test-first e integrazione...
fcirillo: ok per tutti? |
pbossi: ok|
varvello: yeah! |
fcirillo: Se si' davide fuori il problema!!|
varvello: Alura, il mio problema e': ...
varvello: mio zio :-) bob martin dice che le slice devono
rappresentare delle feature...
varvello: e se ho capito bene degli use case.. La mia domanda e':
"solo con l'esperienza si
    riesce..."
varvello: ad individuare queste slices oppure ci sono degli approcci,
spero, ...
varvello: metodologici?|
fcirillo: giuliano, qualche idea al riguardo? |
pbossi: credo che xp direbbe: vai la cosa che ha maggior
senso/consegna maggior valore...
pbossi: ...al tuo committente, rispettando la timeslice impostata.
pbossi: Cioè...
pbossi: concordare con il committente il ranking delle sue richieste
(user stories, poi magari
    approfondiamo il rapporto tra user story e use case)...
pbossi: e cercare di implementare quelle più importanti nell'ordine
che ha maggior senso e
    mantenendo l'orizzonte temporale impostato dalla slice.
pbossi: Tra l'altro...
pbossi: il bello di xp è che (se non ho capito male) non vincola a
grandezze difficilmente
    gestibili come gli use case, ma favorisce lo split delle user story
direttamente concordato
    con il committente in caso di complessità non gestibile nei tempi
settati.
pbossi: |
varvello: mmmm |
fcirillo: davide segui quando giuliano dice user story e parla di xp?
sai cosa e' una user story?
    |
varvello: io identifico abbastanza la user story on lo use case...
fcirillo: giuliano, davide vuole sapere se c'e' un metodo per tirare
fuori queste slice. |
varvello: o meglio con uno use case "piccolo"|
varvello: credo che francesco abbia centrato il punto |
pbossi: ecco, qui sono in difficoltà: come si determina il giusto time
slice? perchè 2 settimane
    piuttosto che 2 mesi?
pbossi: 'mo arrivo, mi rispondo da solo...
fcirillo: cerchiamo di riprendere il discorso dall'inizio e aggiustare
un po' le premesse...
fcirillo: scusa giuliano finisci prima tu|
pbossi: ...la dimensione non è credo fondamentale, è credo la +
piccola possibile (controllo)
    che consente di consegnare un valore significativo al committente
(così è contento di
    pagarti)...
pbossi: ...non solo, gli consente anche di darti feedback...
pbossi: Il punto scabroso è comunque secondo me la granularità delle
user story, come
    dicevamo prima...
pbossi: ...qui non riesco ad andare molto in là della propria
sensibilità: una user story nasce
    da un bisogno raccontato dal committente...
pbossi: ...non necessariamente coincide con uno use case, magari più
con una system
    interaction (cioè una parte coesa di uno use case, giusto
Francesco?)...
pbossi: ...e comunque la sua dimensione dipende al 100% dalla capacità
del team di
    stimarla (molto importante questo) ==> se non riesco a stimarla con
una ragionevole
    tranquillità allora cerco di splittarla con il committente.
pbossi: |
fcirillo: vediamo di riprendere dalla premesse:...
fcirillo: nell'articolo martin focalizza...
fcirillo: sull'importanza del feedback...
fcirillo: e dell'uso di un processo di sviluppo come mezzo per
produrre dati...
fcirillo: il punto ora e': ...
fcirillo: su che cosa misurare...
fcirillo: demarco individua il concetto di binary deliverable...
fcirillo: una buona idea direi...
fcirillo: sapere se una cosa e' fatta o no ...
fcirillo: e' sempre un passo avanti rispetto a frasi:
fcirillo: del tipo...
fcirillo: "abbiamo quasi finito", "non manca troppo" e co.
fcirillo: ...
fcirillo: demarco dice: di solito abbiamo un binary deliverable alla
fine del progetto...
fcirillo: martin dice facciamo in modo che il nostro progetto sia
costituito di n binary
    delverable...
fcirillo: ognuno dovra' poter rispondere in modo non ambiaguo alla
domanda:...
fcirillo: finito? (si/no)...
fcirillo: ok...
fcirillo: come strutturare un progetto in bd?
fcirillo: martin fa capire che un progetto dovrebbe iniziare con
un'attivita' di analisi ...
fcirillo: generale, una sorta di investigazione...
fcirillo: e poi sviluppare i binary deliverable.
fcirillo: piu' sono questi binary deliverable piu' potro' raccogliere
dati ed ottenere feedback...
fcirillo: siamo d'accordo finora? davide, giuliano|
pbossi: "fin qui, tutto bene!" ;-)
varvello: sono d'accordo|
varvello: ok|
fcirillo: ok...
fcirillo: ora domanda che natura hanno questi binary deliverable? ...
fcirillo: non hanno certamente natura di puro sforzo, in quanto non
sarebbe riconoscibile dal
    nostro...
fcirillo: cliente...
fcirillo: il nostro cliente sa riconoscere e apprezza valore...
fcirillo: solo se infatti si tratta di pezzettini di valore
consegnato, il nostro cliente potra' ...
fcirillo: dirci si' mi hai risolto il problema!...
fcirillo: dunque i bd sono pezzettini di valore che consegnamo poco
per volta al nostro
    cliente...
fcirillo: tradotto in ingegneria del software riusciamo ad applicare
un processo...
fcirillo: iterativo (= poco per volta) incrementale (=pezzettini di
valore)...
fcirillo: se decidessimo di consegnare pezzettini di valore poco per
volta ma molto
    frequentemente...
fcirillo: avremmo un processo strict iterative and incremental...
fcirillo: ora...
fcirillo: possono questi pezzettini (slice) di valore essere gli use
case?
fcirillo: ...
fcirillo: gli use case rappresentano valore consegnato all'utente, ma
la maggior parte delle
    volte...
fcirillo: sono trasversali rispetto al progetto...
fcirillo: cerchiamo di essere piu' chiari...
fcirillo: prendiamo un qualsiasi sistema dotcom...
fcirillo: un tipico use case da sviluppare sara': BuyItem...
fcirillo: questo use case non ha la granularita' come diceva
giuliano...
fcirillo: per consentirmi di ottenere un frequente feedback...
fcirillo: quando lo avro' completato, saro' gia' molto in la' con i
tempi, forse anche troppo ;->
fcirillo: finora tutto ok? davide, giuliano?
fcirillo: |
varvello: ok...
pbossi: ok, ok
varvello: solo una chiarificazione .com sta per e-business? |
fcirillo: dunque dove trovare queste slice di valore molto piccole...
fcirillo: si davide per .com
fcirillo: chi puo' darmi queste slice?
fcirillo: direi il cliente!
fcirillo: una user story come diceva giuliano rappresenta una
necessita' esposta dal cliente:...
fcirillo: qualcosa del tipo "ho un grosso problema, devo fare questo
questo e questo..."@
fcirillo: ...
fcirillo: se il problema esposto dal cliente e' troppo grosso...
fcirillo: lo splittiamo in un'altra card. (davide sai che le user
story si scrivono su card?)...
varvello: yes|
fcirillo: nel far questo lavoriamo con strumenti quali: coesione,
chiarezza, non ambiguita',
    atomicita' e co...
fcirillo: tipici del requirement elicitation tradizionale...
fcirillo: vedi davide...
fcirillo: jacobson (inchino) per descrivere uno use case scrive "a
related course of actions"...
fcirillo: che consegna valore all'attore che lo ha iniziato...
fcirillo: le azioni correlate prese singolarmente non consegnato il
valore richiesto dal cliente...
fcirillo: ma partecipano alla sua costituzione...
fcirillo: le slice rappresentano quindi user story (di xp) o related
actions o system interactions
    (requirements analysis di jacobson)...
fcirillo: lasciamo finire dicendo che contrariamente ad un processo
tradizionale,...
fcirillo: xp non richiede un approccio olistico, dove tu conosca tutto
(tutti gli use case, o tutta
    l'analisi) sin dall'inizio...
fcirillo: ma richiede un approccio evolutivo dove sia tu sia il
cliente imparerete quello che
    vorrete, pian piano...
fcirillo: a mano a mano che conoscerete il sistema: costruendolo....
fcirillo: davide ho risposto alla tua domanda? giuliano? |
pbossi: dalla mia parte sfondi una porta aperta!
pbossi: smiles happily
varvello: ok...
varvello: ma, davideNellaParteDellAvvocatoDelDiavolo...
varvello: queste slices sono comunque correlate e la mia
preoccupazione e' quella di...
varvello: non essere in grado di dare una valutazione di massima...
varvello: Vi faccio un esempio:...
varvello: voglio mettere in piedi un meccanismo di, bho, "Scommesse
on-line sui cavalli"...
varvello: che domande mi fareste voi per individuare le slice? |
pbossi: che cos'è e come funziona una scommessa sui cavalli?
fcirillo: buona domanda giuliano |
fcirillo: un'altra domanda per te davide...
fcirillo: quale problema devi risolvere |
pbossi: io concentrerei tutta la mia attenzione iniziale sul dominio,
per poi costruirci attorno i
    servizi che il committente vuole rendeere accessibile|
fcirillo: ok non chiamiamolo dominio...
varvello: si', scusa sono un po' confusionario...
fcirillo: e' molto piu' semplice e comprensibile se pensiamo al
cliente...
fcirillo: lui ha un problema, non riesce a fare qualcosa...
fcirillo: che per lui ha valore...
fcirillo: e noi abbiamo interesse a risolvere il SUO problema |
fcirillo: e' un po' come quando il paziente dello psicologo si mette
sul lettino e il dottore gli
    chiede che problemi ha?|
fcirillo: quanto a produrre una macrostima...
fcirillo: raccogliero' le storie del cliente, le stimero' e ...
fcirillo: se avere una macrostima e' qualcosa che interessa al
cliente...
fcirillo: ne faro' la somma. |
fcirillo: dai davide rispondici sempre da davideAvvocatoDelDiavolo...
fcirillo: ci piace di piu' :-)|
varvello: :-) ok...
varvello: io macrostimo 3 mesi di lavoro...
fcirillo: per far cosa 3 mesi, completare il progetto? |
varvello: per completare il progetto. ...
varvello: e le mie stime sono stime che io giudico sensate...
varvello: cosa succede pero' se nelle slices in mezzo al progetto,
devo utilizzare ...
varvello: una tecnologia di cui non sono espertissimo, questo mi
rallenta, e non credo che il
    customer sia tanto felice|
fcirillo: se si tratta di tecnologie...
fcirillo: in xp, generalmente prima di iniziare lo sviluppo ti prendi
del tempo per fare degli
    spike...
fcirillo: davide sai cosa sono? |
varvello: dovrebbero essere degli esperimenti, giusto?|
fcirillo: si' delle "rogne architetturali"...
fcirillo: il tempo per fare gli spike puo' variare ovviamente...
fcirillo: vai avanti davide|
fcirillo: tira fuori i tuoi dubbi, e' importante
fcirillo: |
varvello: non vorrei rompervi troppo le scatole con le mie paranoie
:-) perche' forse dovrei
    tentare di fare piu' esempi concreti....
fcirillo: si ' ci piacciono di piu' gli esempi concreti, sono quelli
che dobbiamo risolvere. ma vai
    avanti tutti qui abbiamo avuto dubbi|
pbossi: "avuto" ==> io vivo di dubbi continui ... :-)
varvello: e' diciamo piu' un fatto dovuto alla mi abreve esperienza
lavorativa per cui mi sembra
    sempre di avere poco la situazione sotto controllo|
fcirillo: vedi davide il problema vero...
fcirillo: nella realta' e' lavorare per il cliente...
fcirillo: e non per il processo...
fcirillo: o per produrre documenti inutili...
varvello: laughs out loud
fcirillo: i binary deliverable sono codice eseguibile...
fcirillo: che risolve o meno i problemi del cliente...
fcirillo: quando eseguo quel codice...
fcirillo: il cliente mi puo' dire "e'questo!" "no. questo non va" o
"e' questo, ma ora che lo vedo
    ho cambiato idea"...
fcirillo: per me va tutto bene perche' la sto lavorando per consegnare
il valore che lui ...
fcirillo: realmente chiede e non -ad esempio- il valore che mi aspetto
che lui domani possa
    chiedere...
fcirillo: piu' avviene questa comunicazione su pezzi di codice
funzionante piu' sono contento...
fcirillo: il vero problema e' rendere quel codice "malleabile" far si'
cioe' che qualsiasi modifica
    che dovro'...
fcirillo: apportare al codice non mi costi troppo...
fcirillo: lo vedi che abbiamo tutti lo stesso obiettivo? davide,
(giuliano penso sia d'accordo) |
pbossi: confermo
varvello: ok|
pbossi: sulla completezza del progetto...
pbossi: quando un progetto è completo?
pbossi: di fatto...
fcirillo: davide non pensare far questo sia facile. bisogna essere
degli esperti sviluppatori (se
    vuoi esperti ingegneri del software)|
pbossi: non è **mai** completo :) o meglio lo è sempre fintanto che il
committente è contento
    e paga!!
pbossi: |
fcirillo: davide e' chiaro cosa dice giuliano? |
[...]
varvello: alla fine del proj potro scommettere, consultare delle
statistiche sulle corse, ...
varvello: sui cavalli vincenti...
varvello: nelle corse precedenti, i favoriti...
varvello: il cliente e' contento ed io avrei finito...
varvello: ma potrei comunque andare avanti nell'analisi e fornire dei
dati a cui il cliente non ha
    pensato...
varvello: dico una banalita': ad esempio l'oroscopo giornaliero del
fantino per sapere se e' in
    luna buona...
varvello: questo intendo col fatto che un progetto non e' mai finito|
fcirillo: davide se facessi una buona analisi l'oroscopo del fantino
cercheresti di consigliarlo
    prima, in modo ...
fcirillo: da prepararti e non dover modificare tutto domani...
fcirillo: penso sia nell'esperienza di tutti che anche piccole
modifiche possono ...
fcirillo: costringerti a rifare il progetto se non previste in tempo.
|
varvello: ma questo non sarebbe un waterfall?...
varvello: l'oroscopo mi sembra secondario ed io posso aggiungere
questa feature dopo|
fcirillo: a rischio di rifare tutto, siamo d'accordo su questo?!
fcirillo: probabilmente no, ma ho visto progetti da rifare per molto
meno...
fcirillo: e' assolutamente un waterfall, ma questo e' quello che mi
comunica leggere:...
fcirillo: alla fine dei tre mesi consegno questo questo e questo...
fcirillo: e poi ricomincio l'analisi...
fcirillo: giuliano hai qualche idea al riguardo? |
pbossi: è anticipazione, chiaro come il sole...
pbossi: è giusto suggerire business al cliente, ma questo non deve
essere confuso con
    l'anticipazione
pbossi: il punto è riuscire a produrre codice in un modo che sia
facilmente modificabile (come
    diceva Francesco prima)
pbossi: credo veramente che questa sia la chiave di tutto|
fcirillo: davide cerco di essere piu' chiaro se vuoi |
varvello: grazie|
fcirillo: giuliano prima ti voleva comunicare che i progetti evolvono
continuamente...
fcirillo: e su questo mi sembra che anche tu sia d'accordo, giusto |
varvello: giustissimo|
fcirillo: e semmai sono sempre completati visto che continuamente
ricevo l'ok dal cliente...
fcirillo: il fatto che esista un sistema integrato e testato e
perdipiu' apprezzato e pagato, ...
fcirillo: mi sembra giustifichi l'iperbole di giuliano...
fcirillo: fino a questo punto e' tutto ok? |
varvello: si|
fcirillo: |
fcirillo: ora il problema e' come realizzare questo...
fcirillo: l'esperienza vuole che per evitare problemi con nuovi
requisiti -magari trasversali- ...
fcirillo: si cerchi di anticipare o realizzare funzioni magari non
richieste dal cliente...
fcirillo: ti e' mai capitato davide?
fcirillo: |
fcirillo: il magari trasversali, si riferisce al progetto, dunque
requisiti che ti costringerebbero..
fcirillo: a cambiare molto del progetto se non a convincerti che
rifarlo da capo sia l'ipotesi
    migliore per te e per il cliente|
varvello: mi e' capitato|
fcirillo: ok avevamo letto questo tra le righe del tuo intervento...
fcirillo: sbagliamo? |
varvello: no non sbagliate...
fcirillo: ottimo davide! apprezzo la sincerita'...
fcirillo: il problema e' che anticipando non rendiamo il codice
malleabile come dico io...
varvello: spesso mi e' capitato che sia anche tutto il team di
sviluppo che consiglia di
    prendere in esame il piu' possibile tutto|
fcirillo: lo predisponiamo verso i cambiamenti che noi aspettiamo che
il cliente ci chiedera'...
fcirillo: ma non verso quello che lui effettivamente chiedera' (e che
puo' non sapere all'inizio)...
fcirillo: giusto davide su tutto il team]
fcirillo: ovviamente davide anticipare comporta un aumento della
complessita' da gestire...
fcirillo: = gestire complessita' con complessita'...
fcirillo: ecco xp propone di approcciare il cliente fornendogli
esclusivamente quello che ci
    richiede e seguendo un approccio del tipo...
fcirillo: gestire la complessita' con semplicita'...
fcirillo: ripeto il problema sara' capire come...
fcirillo: tu hai delle idee?
fcirillo: e' chiaro ora il punto precedente davide? giuliano tutto ok?
|
pbossi: ok
varvello: mi sembra che xp proponga: la cosa + semplice possibile ed
il refactoring|
pbossi: è vero...
pbossi: ma solo da un punto di vista del puro sviluppo; xp è in realtà
un insieme combinato di
    tecniche, tra cui anche il test-first, il pair-programming, un modo
diverso di approcciare il
    problema, e quindi un processo diverso, ecc.
pbossi: |
fcirillo: e perche' si risolverebbe il problema cosi'? perche non
avrei bisogno di anticipare?
    niente piu' paura di nuovi indesiderati requisiti? davide,
giuliano?
varvello: io avrei paura :-) ...
varvello: scherzo...
pbossi: adoro i nuovi requisiti (==> se ho gli strumenti giusti x
affrontarli <==) ...... altrimenti,
    PANICO!
pbossi: io non scherzo!
pbossi: diciamocelo, è proprio così:...
varvello: l'idea se ho capito bene e' che sono abbastanza flessibile
da poter affrontare i nuovi
    requisiti|
pbossi: "oddio, quel bastardo ha cambiato idea di nuovo, adesso vuole
anche la stampa di
    ogni eseguito e il bip a schermo ..."
pbossi: |
fcirillo: davide, dovremo trovare modi per ridurre il costo del
cambiamento...
fcirillo: perche' e' questo che ci consente di fare buoni progetti...
fcirillo: e' umano che non si sappia quello che si vuole all'inizio
del progetto...
fcirillo: e' umano che il cliente voglia cambiare e aggiungere
requisiti...
fcirillo: noi dobbiamo aiutarlo e non ostacolarlo...
fcirillo: abbiamo bisogno di strumenti che ci aiutino a far questo...
fcirillo: (non quindi a scrivere il codice velocmente ;->)...
varvello: smiles happily
fcirillo: chiaro?|
pbossi: altrimenti mi installo subito ROSE e genero milionate di righe
di codice...
pbossi: ...INUTILE!
varvello: chiaro|
fcirillo: direi di aggiornarci alla prossima settimana... che ne
pensate...
fcirillo: |
varvello: ok, va bene, ho ancora una milionata di domande, ma le posso
rimandare....
pbossi: io purtroppo (o x fortuna) sabato prox non ci sarò, vado via
con mia moglie, ma tra 2
    settimane è ok!
fcirillo: [per davide, non so ancora se xp mi aiutera' a far questo e
come...;->]
fcirillo: se volete possiamo continuare un altro po'... decidete |
varvello: va bene cosi', mi scrivero' le omande, cosi' posso essere
piu' preciso|
fcirillo: allora vi chiedo di osservare la regola numero 4 della
nostra chat...
pbossi: fatemi sapere se chattate sab prox io sarò dei vostri il 16 e
grazie a entrambi, mi sono
    divertito molto!
fcirillo: 4: mandare un feedback sulla chat alla e-mail della lista...
****************CUT HERE****************

Il mio feedback è estremamente positivo (mi sono proprio divertito!),
e devo dire che è stato molto produttivo avere in Davide anche un
"avvocato del diavolo".
Abbiamo sempre + argomenti rispetto al tempo a disposizione, forse
dobbiamo cercare di essere + effettivi, ma la produttività (il numero
e la qualità di ciò che è stato espresso nell'unità di tempo) a mio
avviso è stata comunque molto buona.

Sono curioso di approfondire le domande di Davide e di avventurarci
sugli infidi terreni di test-first (ancora una volta) e
dell'integrazione.

Giuliano

Ciao Folks,

Sabato non ci sono in chat (sono in giro :-) ma vi
propongo comunque degli argomenti, potremo
discuterne quando volete.

Il tema fondamentale e':
Quando una cosa e': "La piu' semplice possibile"
ed invece quando e' solo, per cosi' dire, una
"banalita'", una "svista".

I sottotemi:
1) Ci sono dei compromessi?
2) Vale sempre l'OCP in XP?...
3) ...e gli altri principi di design rimangono o
devono essere rivisti?

bye
  DavideDubbioso :-)




__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/