>Non sono ancora sicuro di venire su. Al momento lo darei al 60%.
>
Beh, sono gia' deliziato che tu abbia pensato di venirmi a sentire!


>Nella premessa accennerei alle "(10-15 modifiche alla logica di
>Business per giorno!)" di cui parli via email.
>
Yup! L'avrei fatto a voce, ma comunque vedro' di inserirlo.


>(Sulla presentazione mancano diversi rami descritti nella mappa)
>
Si, conto di finirlo stasera, in realta' della mappa c'e' ben poco: arriva
in pratica fino al 2o ramo ("Ritmo!")


>Slide 2:
>un'analisi, potrebbe diventare un documento di analisi
>
Ok! Mi piace, introduce anche l'idea di "document-oriented", cerchero'
comunque di non accoppiare le cose.


>Slide3:
>a volte non sappiamo come funzioni (ma funziona). Forse, a volte non
>sappiamo /perche'/...
>Inizialmente non avevo capito (ne' io, ne' i ragazzi con cui stiamo
>lavorando) che per calcolatore intendessi una calcolatrice (ti99 ci
>ha poi illuminato ;-)) e avevo scritto
>Calcolatore -> Serie
>
No, non capisco io qui :-). Cosa intendi?


>Relativamente all'esempio...
>Nel primo test scrivi
>Calcolatore ti99 = new Calcolatore();
>int media = ti99.media(valori);
>assertEquals(5, ti99.media(valori));
>
My fault! Cut&PasteException :-D


>- Non mi piace molto ti99.media(valori), preferirei qualcosa tipo
>values.average(); values potrebbe essere un'istanza di Serie o
>altro...
>
Vorrei se possibile mantenere tutto in italiano (causa platea) e non
introdurre troppa carne al fuoco: quindi anche se un po' di OO manca, non mi
preoccupo, il mio problema e' fare capire TDD. Poi magari te li mando li' a
Roma :-)

Per le altre osservazioni all'esempio confermo quanto gia' detto a Alberto &
co.


>- regredisce = degenera?!
>
Regredisce nel senso che riappaiono dei bug o addirittura delle funzioni che
erano state eliminate precedentemente. Non avendo test che ti fanno da
anti-regressione, e' probabile che durante lo sviluppo del tuo software tu
reintroduca dei bug che avevi eliminato.


>> - "I QA possono svolgere attivita' non solo di controllo ma
>> contribuiscono all'evoluzione" - potresti chiarirmi un po' il
>> concetto?
>
>Riprendi il concetto di Kent, portandolo fino a che punto?
>
Mah, mi piacerebbe denotare il fatto che i QA invece di rompere solo possono
anche essere degli ottimi collaboratori, fino a proporre, insieme a te,
nuove funzionalita' invece di fare finta di niente (e rompere :-D)


Ciao & grazie,

     Bruno.

Hello Bruno,

Monday, July 1, 2002, 2:18:18 PM, you wrote:

BB> Uhm... guarda che Kent nel libro su TDD (puoi scaricare il draft
BB> dalla lista ci metterebbe addirittura "return 5;" nel primo
BB> passaggio: poi si accorgerebbe che in

il libro ce l'ho in ufficio. Gli daro' una rilettura...

>>Mi spiace non averlo saputo prima, sarei venuto volentieri a seguirti.

BB> Addirittura! Mi sento onorato!

Maddai :)

Per l'XTC, beh... e' ogni martedi.
Io non ci vado sempre, e' un po' nerd-night :-)... pero' se qualcuno
di voi sale a londra ci andiamo insieme.

Qualche mese fa ci ho portato Ugo Landini (che pure scriveva qui o in
it.comp.java...).
E' cmq interessante, ci sono vari XPers con varie esperienze.

a presto,
Paolo.

--- In extremeprogramming-it@y..., paolo.polce@b... ha scritto:

> Dunque, per l'esempio specifico, trattandosi di una media di
interi, io scriverei
>
> il metodo che ritorna "zero", giusto per evitare errori di
compilazione, poi:
>
> testNessunValore()
> testUnValore()
> testDueValori()
> testMoltiValori()
>
> lancerei JUnit e vedrei 4 test falliti.
>
> Poi scriverei il codice.
> Vista la semplicita', forse avrei tutti e 4 i test passati al
primo colpo.
>
Il vantaggio di scrivere un test alla volta e' quello di farsi
guidare dal test stesso per scrivere non solo il codice applicativo,
ma anche i successivi test, cioe' farsi guidare dal codice per
ottenere il miglior design (piu' semplice e piu' comunicativo).
Questa alternanza fra codice di test e quello applicativo ti
consente un ritmo e un modo di procedere incrementale che ti
supporta nel rimanere focalizzato. E poi, avere una sola barra rossa
alla volta consente di procedere con piu' tranquillita'.

> Se e' un "esempio" di come si approccia un problema piu' generale
allora (e lo dicevo a bruno) sono d'accordo, a patto che a parole si
renda chiaro.
Per quanto semplice possa essere la formula da implementare, trovare
il miglior design non e' mai facile in modo anticipatorio. Scrivere
4 test alla volta equivale ad anticipare tutto il design, senza
avvalersi del supporto del feedback dato dal codice.

--Luigi Mengoni, Marco Dani (Team Pongo)

Hello luigi_unirel,

Tuesday, July 2, 2002, 2:07:13 PM, you wrote:

l> Il vantaggio di scrivere un test alla volta e' quello di farsi
l> guidare dal test stesso per scrivere non solo il codice applicativo,
l> ma anche i successivi test, [...]
l> avere una sola barra rossa
l> alla volta consente di procedere con piu' tranquillita'.

Siamo d'accordo. Ma dico, e _ripeto_, non e' il caso del
calcolatore.
E' un esempio talmente semplice che sinceramente non vedo il motivo di
giocare a ping pong con JUnit.

Poi, credo, e' parte dello stile di ciascuno...

l> Per quanto semplice possa essere la formula da implementare, trovare
l> il miglior design non e' mai facile in modo anticipatorio.

Non ho fatto nessun design upfront.
Voglio scrivere un _calcolatore_ e voglio che questo rispetti alcuni
test.
Se poi nello scrivere il codice che rispetta quei test, mi accorgo che
forse ho bisogno di aggiungere/modificare/cancellare un test lo
faccio.

l> Scrivere 4 test alla volta equivale ad anticipare tutto il design,
l> senza avvalersi del supporto del feedback dato dal codice.

Anticipare il design? E in che modo?


P.

Ciao,
evidenzierei che comunque lavorare con TDD non significa inziare a
codificare immediatamente ma ti permette di farlo il prima possibile.
Vengono comunque, prima, il planning game gli User Test le carte o comunque
i metodi per comprendere quello che il cliente vuole poi grazie al TDD
scriverai del buon codice ma non è detto che scriverai la soluzione
migliore(anche se a volte le cose sono legate).
Per mia esperienza ho notato che come programmatore ho sempre guardato di
buon occhio tutto ciò che mi permettesse di codificare il prima possibile
magari perdendo di vista le reali esigenze del cliente o dando vita alle
famose "incomprensioni".

Marco De Toni
marco.detoni@...

Allos spa
via Borgo Padova 170
35013 Cittadella (PD)
Tel +39 0499414411 Fax +39 0499414430

Volevo solo farvi sapere che e' online la nuova versione delle slide
su TDD, sempre a:
http://digilander.iol.it/bbossola/seminari/tdd/main.html
Forse non ho ancora finito di integrare tutto il feedback: asap la
versione candidate.

Inoltre e' online anche la prima parte della presentazione di XP a:
http://digilander.iol.it/bbossola/seminari/xp/main.html
Penso che per il resto delle slide usero' la vecchia presentazione di
zio Bob, rinfrescandola un po'.

Ciao,

    Bruno.

Hello bruno_bossola,

Tuesday, July 2, 2002, 10:36:59 PM, you wrote:

b> Volevo solo farvi sapere che e' online la nuova versione delle slide
b> su TDD, sempre a:
b> http://digilander.iol.it/bbossola/seminari/tdd/main.html
b> Forse non ho ancora finito di integrare tutto il feedback: asap la
b> versione candidate.

manca il testNessunValore(), secondo me.
Se chiami la tua funzione con un array nullo becchi un
NullPointerException quando chiedi "valori.length"

se invece l'array non e' nullo, ma vuoto, becchi un DivisionByZero
quando fai return somma/valori.length

ecco perche' insisto sul mio amatissimo testNessunValore() :-))


P

>evidenzierei che comunque lavorare con TDD non significa inziare a
>codificare immediatamente ma ti permette di farlo il prima possibile.
>Vengono comunque, prima, il planning game gli User Test le carte o comunque
>i metodi per comprendere quello che il cliente vuole poi grazie al TDD
>scriverai del buon codice ma non è detto che scriverai la soluzione
>migliore(anche se a volte le cose sono legate).
>
TDD non specifica un processo ne' un metodo, e' solo un modo per sviluppare
software. Comprendere le specifiche del cliente viene gestito dal metodo che
adotti (RUP, XP, ecc.) e TDD e' neutro rispetto a questo. D'altra parte
comprendo perfettamente il problema, cerchero' di ricordarmi di dirlo anche
a voce. Al limite fammi una domanda :-D


P.S.
Per il PC sono riuscito alla fine ad aggiustarmi con un portatile della
ditta, ma grazie lo stesso!

Ciao,

     Bruno.

>Se chiami la tua funzione con un array nullo becchi un
>NullPointerException quando chiedi "valori.length"
>
Beh, puo' darsi che questo mi vada bene, ma hai ragione, dovrei testarlo.
Lo diro' senz'altro a voce.

Ciao,

     Bruno.

--- In extremeprogramming-it@y..., "Bruno Bossola" <bbossola@c...> ha
scritto:

> Non c'e problema se in TDD scelgo di fare un po' di design prima di
> approcciare il problema,  ne devo semplicemente essere conscio e
> consciamente decidere di mantenere il mio proprio gap fra la
decisione di
> design e il feedback che mi verra' dalla scrittura del codice. Cito
> direttamente Kent:
>
> "Readers of Extreme Programming Explained will notice a difference
in tone
> between XP and TDD. TDD isn’t an absolute like Extreme Programming.
XP says,
> “Here are things you must be able to do to be prepared to evolve
further.”
> TDD is a little fuzzier. TDD is an awareness of the gap between
decision and
> feedback dur-ing programming, and techniques to control that
gap. “What if I
> do a paper design
> for a week, then test-drive the code? Is that TDD?” Sure, it’s
TDD.
You were
> aware of the gap between decision and feedback and you controlled
the gap
> deliberately."

OK. Ma allora specifica la "difference in tone" tra XP e TDD e
chiarisci il tuo punto nella presentazione.

Ciao

--Francesco

Ciao Paolo,

--- In extremeprogramming-it@y..., paolo.polce@b... ha scritto:
> >Paolo scrive:
> >"1) L'esempio sul calcolatore e' ok, [...]
> >"Vederlo" e' un conto testarlo e' un altro.
> >Quindi proponi di scrivere l'algoritmo della >media al primo step
(errore di compilazione)?
> Dunque, per l'esempio specifico, trattandosi di una media di
interi, io scriverei
> il metodo che ritorna "zero", giusto per evitare errori di
compilazione, poi:
> testNessunValore()
> testUnValore()
> testDueValori()
> testMoltiValori()
> lancerei JUnit e vedrei 4 test falliti.

Personalmente non ritengo molto efficace l'idea di scrivere n test
insieme (trovo sia un approccio per complicare il proprio lavoro). In
qualsiasi situazione, nella costruzione del sw, voglio poter lavorare
su un nuovo test alla volta.

> Poi scriverei il codice.
> Vista la semplicita', forse avrei tutti e 4 i test passati al primo
colpo.

Forse si', forse no. Nel primo caso dubiterei. Nel secondo caso
potrei perdere molto tempo a mettere le cose a posto.

> Non vedo la necessita' di andare avanti e dietro a modificare un
pezzettino piccolo piccolo di codice, vista la semplicita'
dell'esempio.

Il mio punto e' che se lavoro sempre test dopo test in modo
incrementale e rifattorizzando, qualsiasi funzionalita' da aggiungere
non sara' mai eccessivamente complicata (questo mi piace molto).

La values.average() mi piace ed e' venuta "lasciandomi stupire dal
codice", lavorando un test alla volta. Risolvendo il problema in
maniera evolutiva ho messo poco tempo, ho imparato diverse cose di
design (non serve un oggetto calcolatore, l'assunzione int average
(..) doveva essere invece double average...), ho trovato nuovi test
che non avevo considerato inizialmente.

> Davvero modificheresti il codice quattro volte per scrivere una
media di interi?

Come gia' scritto, l'ho fatto. Ho considerato la media di interi la
prima funzionalita' di un sistema in evoluzione.

Immaginavo che Bruno volesse dare una dimostrazione di come
realizzare una funzionalita' attraverso il test-first incrementale
alla XP.

Dal mio punto di vista il problema non e' la complessita'
dell'algoritmo della media, ma come - arrivare a (nell'ottica
evoluzionista) - strutturare le relative logiche applicative
minimizzando la complessita' del sistema (ad esempio, quando lavoravo
nel financial engineering, tra i tanti, l'approccio di design piu'
efficace per calcolare la media aritmetica era attraverso una sorta
di Bag). Per lavorare nella predetta direzione applico il test-first
incrementale perche' lo ritengo molto efficace.

Mi piace pensare che il mio codice sia malleabile. Non ho paura, ne'
fastidio di modificare il codice n volte per scrivere una media di
interi sempreche' si arrivi a ridurre la complessita' del mio
sistema. Il "ping-pong" con junit mi da' molta tranquillita' e
velocita'.

In quale caso non avrei lavorato cosi'?
->Il sistema da realizzare consiste solo di algoritmo di media AND
->Il sistema non e' critico AND
->L'implementazione della funzionalita' non e' soggetta a scadenza AND
->Il sistema non e' soggetto ad alcun cambiamento AND
->Bruno non deve dare un esempio di test-first incrementale alla XP ;-
)

--Francesco

--- In extremeprogramming-it@y..., Paolo Polce <paolo.polce@b...> ha
scritto:

> Siamo d'accordo. Ma dico, e _ripeto_, non e' il caso del
> calcolatore.
> E' un esempio talmente semplice che sinceramente non vedo il
motivo di
> giocare a ping pong con JUnit.
E' come dire che l'oggetto MoneyBag nell'esempio di Beck sia stato
individuato da subito.
>
> Poi, credo, e' parte dello stile di ciascuno...
Lo stile si esprime nella componente creativa e non nel tipo di
approccio che usi: ad esempio in TDD scrivi un test alla volta e
questo fa parte dell'approccio (o metodo), ma e' in come scrivi il
codice di test e applicativo che entra in gioco anche il tuo stile
(creativita'). Crediamo comunque che sia piu' complesso testare,
gestire il design e rifattorizzare partendo dall'implementazione di
tutti i test; quindi per noi e' piu' semplice e quindi crediamo
efficace e migliore per la qualita' finale procedere nel modo
descritto.

> Non ho fatto nessun design upfront.
Scegliere quale struttura implementera' il comportamento richiesto
e' diverso -e per noi meno efficace - dal far emergere la struttura
dal comportamento: il comportamento dell'esempio puo' essere piu'
una "collezione che puo' fare la media", che non di un calcolatore.
Sempre che si sia liberi di dare un'interfaccia propria all'oggetto.

> Voglio scrivere un _calcolatore_ e voglio che questo rispetti
alcuni
> test.
> Se poi nello scrivere il codice che rispetta quei test, mi accorgo
che
> forse ho bisogno di aggiungere/modificare/cancellare un test lo
> faccio.

Cio' che volevamo dire e' che, non anticipando, otteniamo un codice
piu' flessibile, quindi piu' aperto al cambiamento. E' frequente il
fatto di aver pensato un oggetto X, e mentre ne implementavamo i
test, ritrovarsi a dire "ma questo assomiglia piu' a Y" e cambiare
strada facendo.

>
> Anticipare il design? E in che modo?

Ad esempio nel dire "ho bisogno di un calcolatore che soddisfa
questi 4 test" anziche' scrivere subito un test e lasciare che i
comportament e i servizi che l'oggetto espone emergano man mano che
si scrivono i successivi test.

--Team Pongo
Marco Dani, Luigi Mengoni, Alberico Gualfetti

Hello marco_unirel,

Wednesday, July 3, 2002, 2:40:38 PM, you wrote:

>> Poi, credo, e' parte dello stile di ciascuno...

m> Lo stile si esprime nella componente creativa e non nel tipo di
m> approccio che usi:

Molto discutibile, ma abbiamo gia' una "polemica" aperta, percui la
dicussione sulla creativita' la rimandiamo ;-))

m> (creativita'). Crediamo comunque che sia piu' complesso testare,
m> gestire il design e rifattorizzare partendo dall'implementazione di
m> tutti i test;

A questo punto mi dovete fare il piacere di leggere il mio messaggio di
nuovo.
Perche' io non ho mai detto che scrivo TUTTI i test prima di scrivere
il codice.
Ho detto, e lo ripeto per l'n-ma volta, che nell'esempio particolare
della calcolatrice, essendo molto semplice, mi sono venuti in mente
immediatamente quattro test e li ho scritti.

Poi, e ripeto anche questo, scrivendo il codice puo' darsi che mi
venga in mente di dover cambiare/modificare/aggiungere uno o piu'
test.

Per il caso generale, e' _OVVIO_ che non scrivo _tutti_ i test prima del
codice per tutti i motivi che avete elencato voi e francesco.

anzi, permettimi di quotare quello che ho scritto nel primo messaggio:

PP> Se e' un "esempio" di come si approccia un problema piu' generale
PP> allora (e lo dicevo a bruno) sono d'accordo, a patto che a parole
PP> si renda chiaro.

m> quindi per noi e' piu' semplice e quindi crediamo
m> efficace e migliore per la qualita' finale procedere nel modo
m> descritto.

E sono d'accordo anche su questo. (calcolatrice sempre a parte ;-)).

>> Non ho fatto nessun design upfront.

m> Scegliere quale struttura implementera' il comportamento richiesto
m> e' diverso -e per noi meno efficace - dal far emergere la struttura
m> dal comportamento:

Dunque... e quale struttura avrei scelto, se non hai nemmeno visto i
test? (nomi dei metodi a parte)

m> Cio' che volevamo dire e' che, non anticipando, otteniamo un codice
m> piu' flessibile, quindi piu' aperto al cambiamento. E' frequente il
m> fatto di aver pensato un oggetto X, e mentre ne implementavamo i
m> test, ritrovarsi a dire "ma questo assomiglia piu' a Y" e cambiare
m> strada facendo.

Verissimo e frequentissimo. Mai dubitato.

>> Anticipare il design? E in che modo?

m> Ad esempio nel dire "ho bisogno di un calcolatore che soddisfa
m> questi 4 test" anziche' scrivere subito un test e lasciare che i
m> comportament e i servizi che l'oggetto espone emergano man mano che
m> si scrivono i successivi test.

Nono scusa... io sono il "customer" di me stesso in questo momento:
voglio una calcolatrice che soddisfi quattro condizioni.

m> --Team Pongo
m> Marco Dani, Luigi Mengoni, Alberico Gualfetti

Piacere.

Paolo.
p.s. polemica l'ho scritto fra virgolette ;-))

Hello francesco_xplabs,

Wednesday, July 3, 2002, 2:33:16 PM, you wrote:

f> Personalmente non ritengo molto efficace l'idea di scrivere n test
f> insieme (trovo sia un approccio per complicare il proprio lavoro).

Beh e' ovvio che "n" e' sempre piu' piccolo quanto piu' grande e
sconosciuto sembra o e' quello che si sta facendo.

Oggi, ad esempio, stavo lavorando su una classe che usa una
connessione http per ottenere il contenuto di una pagina web, la manda
ad un parser ed ottiene alcune info...
In quel caso ho scritto un test alla volta, perche' non solo non mi veniva
facile anticipare il prossimo, ma anche perche' sapevo che il soddisfare
il primo test mi avrebbe portato ad introdurre delle modifiche alla
interfaccia della classe stessa e che quindi, come dici anche tu (e
gli altri tre ragazzi), sarei stato costretto a modificare eventuali
test anticipati e perdere tempo.

Ma, ormai non mi scoccio di ripeterlo ;-), non e' il caso del ti99.

f> Il mio punto e' che se lavoro sempre test dopo test in modo
f> incrementale e rifattorizzando, qualsiasi funzionalita' da aggiungere
f> non sara' mai eccessivamente complicata (questo mi piace molto).

Ed e' una cosa che faccio anch'io, SEMPRE. ;)
E se domani voglio trasformare il mio calcolamedie in qualcosa di
piu' complesso, comincero' a scrivere qualche altro test (forse due
alla volta e non quattro, perche' la struttura si comincia a
complicare).

f> Immaginavo che Bruno volesse dare una dimostrazione di come
f> realizzare una funzionalita' attraverso il test-first incrementale
f> alla XP.

Indubbiamente, ma io mi trovo spesso a confrontarmi con persone che
dicono che noi XPers tendiamo a prendere XP come una religione, percui
se io ad una conferenza dicessi "Ragazzi con TDD si fa UNO ed UN SOLO
test alla volta, SEMPRE", mi sentirei accuse di fanatismo religioso.
Secondo me e' importante dire, anche perche' effettivamente lo
riscontro nella realta', che l'esperienza, i pattern, il gia' visto, a
volte ti consente o ti porta a scrivere un paio di test alla volta...


f> Dal mio punto di vista il problema non e' la complessita'
f> dell'algoritmo della media, ma come - arrivare a (nell'ottica
f> evoluzionista) - strutturare le relative logiche applicative
f> minimizzando la complessita' del sistema [...]

Sono d'accordo.
Vedi, noi ad esempio lavoravamo ad un prodotto (per windows) che fa analisi
contestuale delle pagine web per mostrare informazioni ad esse
associate, consultando vari provider di servizi (un po' come la barra
alexa)...

Era, come dicevo, un applicativo per windows, che utilizzava Atl per
il componente IE ed era, chiaramente, una applicazione client side.

a poco a poco, viste le richieste di mercato (e di conseguenza del
nostro sales team, cioe' il nostro customer) il prodotto e' diventato
server side e gira in maniera distribuita su server linux...

Tutto si puo' cambiare a poco alla volta, ed e' sicuramente un
risultato che senza TDD e MockObjects non avremmo potuto raggiungere.

In un ambiente diverso, infatti, credo che saremmo stati costretti a
"riprogettare" tutto.

f> In quale caso non avrei lavorato cosi'?
->>Il sistema da realizzare consiste solo di algoritmo di media AND

ED E' QUELLO CHE HO DETTO IO!
Voglio una calcolatrice che faccia la media. Punto. Stop. Finished.
Done. That's it. ! ;-))

->>Il sistema non e' critico AND

Giusto.

->>L'implementazione della funzionalita' non e' soggetta a scadenza AND

Giusto.

->>Il sistema non e' soggetto ad alcun cambiamento AND

Hmmm...

->>Bruno non deve dare un esempio di test-first incrementale alla XP ;-)

;-))


Paolo.

Hello Paolo

Ci pare che l'unica differenza sostanziale tra il nostro "modo" e il tuo
consista nel fatto che noi anche per esempi molto semplici preferiamo
affrontare in testfirst un test alla volta e tu no.

--Marco Dani, Luigi Mengoni (Team Pongo)

Ciao,

     volevo solo dirvi che ho aggiornato le slide del mio prossimo
intervento su TDD/XP al prossimo webbit.02, con TDD ormai in "final
candidate" e XP al 90%: se volete dare un'occhiata e darmi ancora un
po' di feedback le trovate dove erano prima, ovvero:

XP:
http://digilander.iol.it/bbossola/seminari/xp/main.html

TDD:
http://digilander.iol.it/bbossola/seminari/tdd/main.html


Grazie ancora per tutte le osservazioni!
Ciao,

     Bruno.

Ciao ragazzi,

   si, direi di si.

Una curiosita': usate MockObjects?

Paolo.


>  from:    Dani Marco <marcod@...>

Hello Paolo

Ci pare che l'unica differenza sostanziale tra il nostro "modo" e il tuo
consista nel fatto che noi anche per esempi molto semplici preferiamo
affrontare in testfirst un test alla volta e tu no.

--Marco Dani, Luigi Mengoni (Team Pongo)

Ciao a tutti,

   brevissimo offtopic: c'e' nessuno che usa eclipse?

P.

Noi saltuariamente. Stiamo facendo un po' di prove e di spike. Gian mi sembra
quello più ferrato.
Immagino che quando lo strumento giungerà a maturazione forse abbandoneremo VAJ
in suo favore. Per il
momento sembra notevole, ma ancora un poco immaturo.

Come mai chiedi?
Ciao, G

paolo.polce@... wrote:

> Ciao a tutti,
>
>   brevissimo offtopic: c'e' nessuno che usa eclipse?
>
> P.
>
> To unsubscribe from this group, send an email to:
> extremeprogramming-it-unsubscribe@egroups.com
>
>
>
> L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle
http://it.docs.yahoo.com/info/utos.html

Io lo sto provando: la versione 2.0 e' impressive, e penso che al 90%
passeremo a quello (attualmente usiamo VAJ).

Ciao,

     Bruno.


-----Messaggio originale-----
Da: paolo.polce@... [mailto:paolo.polce@...]
Inviato: venerdì 5 luglio 2002 14.17
A: extremeprogramming-it@yahoogroups.com
Oggetto: [xp-it] Eclipse



Ciao a tutti,

   brevissimo offtopic: c'e' nessuno che usa eclipse?

P.



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



L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle
http://it.docs.yahoo.com/info/utos.html

Da me stiamo eliminando JBuilder Enterprise per usare tutti Eclipse 2. Il
passo è notevole perchè contemporaneamente abbiamo abbandonato Visual Source
Safe per CVS (per ora sotto NT poi si passa a Linux) e stiamo introducendo
l'uso massivo e sistematico di Ant e JUnit.

Le persone che ci stanno lavorando sono entusiaste: qualcuno aveva già lavorato
con Application Developer di IBM (Eclipse 1) e si trova a suo agio ma anche
chi era solito usare JBuilder non ha rimpianti.

Le versioni prima della 2 avevano qualche problema di stabilità, la 2 finale
è capitato si chiudesse inaspettatamente (sotto c'è W2K) ma la consideriamo
sufficientemente stabile. Confido nell'uscita di plugin "seri" opensource
anche per lo sviluppo visuale e per una vera integrazione con gli application
server: potrebbero fare la differenza in termini di quantità di download.....

Ci sono persone che lavorano con me (ma oggi ieri sono partiti per andare
a vedere Bruno) che stanno usando Eclipse per progetti bancari e, se vorranno
potranno dare un parere più "autorevole" del mio.
Ciao
Matteo

>-- Messaggio Originale --
>To: extremeprogramming-it@yahoogroups.com
>From: paolo.polce@...
>Date: Fri, 5 Jul 2002 13:17:15 +0100 (BST)
>Subject: [xp-it] Eclipse
>Reply-To: extremeprogramming-it@yahoogroups.com
>
>
>
>
>
>
>
>Ciao a tutti,
>
>  brevissimo offtopic: c'e' nessuno che usa eclipse?
>
>P.
>
>
>
>
>
>
>
>
>
>
>Yahoo! Gruppi - Sponsor
>
>
>
>
>
>
>
>
>
>
>
>
>To unsubscribe from this group, send an email to:
>extremeprogramming-it-unsubscribe@egroups.com
>
>
>
>
>
>L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle Condizioni di
>Utilizzo del Servizio Yahoo!
>
>
>
>


__________________________________________________________________
TuttoTISCALI e' il tuo nuovo contratto di telefonia!
Chiami in tutta Italia, giorno e notte, al prezzo di un'urbana
Ti colleghi ad Internet e spendi meno di un'urbana
http://point.tiscali.it/tuttotiscali/webmail.html

grazie a tutti.

Il mio interesse riguarda il fatto che stiamo pensando di migrare da VAJ ad
eclipse (come ho letto anche nelle vs risposte), anzi vorremmo esguire i
seguenti passi

0) Win2K   VAJ   SOURCE SAFE   (conf. attuale)
1) Win2K   VAJ   CVS  (step1)
2) Win2K   ECLIPSE   CVS (step2)
3) Linux   ECLIPSE   CVS (step3)

L'importanza dello step3 e' relativa, ma sicuramente vogliamo ragiungere il due.

Stiamo usando Eclipse nei ritagli di tempo, per familiarizzare un po' con
l'ambiente e ci piace molto.

L'altro motivo e' che sto scrivendo un Plug-In per Eclipse 2.0 per integrare il
mockmaker del mio collega Ivan Moore. (http://www.mockmaker.org)

Scrissi una versione spike per una pre-release di eclipse, ma poi mi fermai in
attesa della 2.0 (con le precedenti versioni c'erano un po' di prob di
stabilita').

Ora che e' uscita la 2.0 mi posso rimettere al lavoro.

A coloro che usano MockObjects consiglio provare il mockmaker e magari darmi una
mano per il plugin, anche se solo intermini di feedback.

Paolo.

Dal mese scorso stiamo facendo una serie di spike su Eclipse 2.0 + CVS su
Linux.

Altri due spike sono previsti relativamente a plug-in e da settembre
prevediamo una review.
> L'altro motivo e' che sto scrivendo un Plug-In per Eclipse 2.0 per
> integrare il mockmaker del mio collega Ivan Moore. (<a
> href="http://www.mockmaker.org)">http://www.mockmaker.org)</a><BR>

Interessante. Dicci qualcosa di piu' al riguardo.

> A coloro che usano MockObjects consiglio provare il mockmaker e magari
> darmi una mano per il plugin, anche se solo intermini di feedback.<BR>

Da parte nostra contaci.

--Francesco Cirillo
Director, XPLabs, S.R.L.
Founder, XPLabs Consortium
http://www.xplabs.com

Hello,

   quello che sto scrivendo e' un tool di integrazione con Eclipse, che permetta
di lanciare il mockmaker su una interfaccia/classe per ottenerne una versione
mock.

Il plugin agisce sull'extension "popupMenus" di Eclipse e filtra oggetti di tipo
IType (cioe' classi e/o interfacce).

Facendo right click su una interfaccia in eclipse, si apre il solito menu che
-oltre alle solite voci- contiene una voce "MockMaker" per generare un mock per
quella classe/interfaccia.

Al momento il plugin e' piu' una spike che altro (non ho scritto nessun test),
visto che e' la prima volta che scrivo qualcosa per eclipse.

Mi farebbe piacere, quindi, postare una versione "spike" qui in area, cosi' da
ricevere commenti, bugs, aiuti da chi ha gia' scritto plugins ecc. ecc.

Paolo.
p.s. per chi non conosce mockmaker, http://www.mockmaker.org



>  from:    Francesco Cirillo
>  subject: Re: [xp-it] Eclipse

--- In extremeprogramming-it@y..., paolo.polce@b... ha scritto:
>
> Ciao ragazzi,
>
>   si, direi di si.
>
> Una curiosita': usate MockObjects?

Fino a ora non ne abbiamo fatto uso in termini di oggetti java, ma
contiamo di utilizzarli maggiormente per il futuro. Le
caratteristiche del progetto attuale ci hanno portato a scrivere
eseguibili "mock"  nativi che vengono lanciati da Java.

--Marco Dani, Luigi Mengoni (Team Pongo)

paolo.polce@... wrote:

>Ciao a tutti,
>
>  brevissimo offtopic: c'e' nessuno che usa eclipse?
>
>P.
>
>
>
>To unsubscribe from this group, send an email to:
>extremeprogramming-it-unsubscribe@egroups.com
>
>
>
>L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle
http://it.docs.yahoo.com/info/utos.html
>
>
>
>
>
Come ambiente è molto promettente tuttavia per chi è abituato a lavorare
con VAJ ci sono degli aspetti che per ora possono essere fastidiosi.
Io,ad esempio, ho creato su un mio repository CVS locale una serie di
progetti java che ho messo sotto un folder 'java' e non riesco a creare
delle versioni con 'version as tag' dei singoli progetti ma solo di
tutto il folder.
Inoltre mi sembra che RMI non sia ancora supportato e quindi per
generare skeleton e proxy devi usare rmic o riuscendo a metterlo nelle
operazioni da eseguire durante il build nella java prospective o,
peggio, andando a modificare direttamente il file xml di ant dalla
resource prospective.
L'applet viewer deve essere configurato come tool esterno e purtroppo
non sono riuscito a lanciarlo facendogli runnare l'applet attualmente
selezionata ma picconando nella configurazione del tool esterno la
specifica applet.
Comuque come ambiente è veramente potente e quindi ne consiglio
l'utilizzo, c'è da tenere presente questi problemi che possono prendere
un'po di tempo.

Giannandrea

Hello marco_unirel,

Monday, July 8, 2002, 1:35:12 PM, you wrote:

m> Le caratteristiche del progetto attuale ci hanno portato a scrivere
m> eseguibili "mock"  nativi che vengono lanciati da Java.
m> --Marco Dani, Luigi Mengoni (Team Pongo)

Non sono sicuro di aver capito che intendete per mock nativi. Sono
oggetti c/c++ lanciati da jni?
Vi spiace farmi un esempio?
Mi interessa sapere i diversi tipi di mock
che i vari programmatori usano.

P

>Altri due spike sono previsti relativamente a plug-in e da settembre
>prevediamo una review.
Scusate, vi vedo parlare di Eclipse, e mi incuriosisco: io gli ho dato
un'occhiata per la prima volta oggi, e devo dire che non mi ha fatto una
grandissima impressione. Oddio, naturalmente l'interfaccia grafica è molto
rapida, ma devo dire che le funzionalità mi hanno un po' deluso. Io sono un
"netbeansiano", uso netbeans da sempre e ho visto questo fantastico pezzo di
software crescere col tempo (quando vidi la prima versione di netbeans, con
quella eccezionale interfaccia swing, 3 anni fa, rimasi di stucco, e trovo
che l'usabilità di Netbeans sia ottima anche oggi). Ma benché la rapidità
dell'interfaccia sia molto meno brillante, trovo che Eclipse sia abbastanza
indietro per una serie di funzionalità che invece in Netbeans sono molto
utili. Ora, non si può dire che l'editor di Netbeans sia avanzatissimo, ma
contiene di sicuro alcune funzionalità molto interessanti: sembra che in
Eclipse non ci sia nulla di simile alle abbreviazioni (in netbeans posso
programmare le cose in modo tale che se scrivo "if<spazio" mi si componga
tutta la struttura di un if ( con "if () {}")), non ho trovato nulla di
simile ad alcune funzionalità di completamento o navigazione di Netbeans
(tipo l'utilissimo ctrl-k che completa la parola che si sta digitando con la
parola precedente che comincia nello stesso modo, o alt-g che salta al
codice sorgente del metodo o della classe sotto il cursore, o ancora alt-k
che consente di "tornare indietro" da un salto di questo tipo). Salta poi
subito agli occhi che alcune cose sono implementate maluccio, come il box
che si apre e mostra il javadoc delle classi di cui si sta facendo il
completamento automatico (in Eclipse tronca il testo dopo un certo punto,
non ci sono scrollbar e non è navigabile, cose che invece sono vere in
Netbeans 3.4). Devo dire poi che ho trovato interessanti le obiezioni che
sono state fatte all'unanime coro pro-eclipse da un altro fan di Netbeans su
theserverside.com (nel thread
http://www.theserverside.com/home/thread.jsp?thread_id=14251 che è oramai
decisamente nutrito di commenti, che generalmente tendono a consigliare
intellij IDEA contro ad Eclipse).

Saluti,
Davide Baroncelli.

Davide Baroncelli wrote:

>>Altri due spike sono previsti relativamente a plug-in e da settembre
>>prevediamo una review.
>>
>>
>Scusate, vi vedo parlare di Eclipse, e mi incuriosisco: io gli ho dato
>un'occhiata per la prima volta oggi, e devo dire che non mi ha fatto una
>grandissima impressione. Oddio, naturalmente l'interfaccia grafica è molto
>rapida, ma devo dire che le funzionalità mi hanno un po' deluso. Io sono un
>"netbeansiano", uso netbeans da sempre e ho visto questo fantastico pezzo di
>software crescere col tempo (quando vidi la prima versione di netbeans, con
>quella eccezionale interfaccia swing, 3 anni fa, rimasi di stucco, e trovo
>che l'usabilità di Netbeans sia ottima anche oggi). Ma benché la rapidità
>dell'interfaccia sia molto meno brillante, trovo che Eclipse sia abbastanza
>indietro per una serie di funzionalità che invece in Netbeans sono molto
>utili. Ora, non si può dire che l'editor di Netbeans sia avanzatissimo, ma
>contiene di sicuro alcune funzionalità molto interessanti: sembra che in
>Eclipse non ci sia nulla di simile alle abbreviazioni (in netbeans posso
>programmare le cose in modo tale che se scrivo "if<spazio" mi si componga
>tutta la struttura di un if ( con "if () {}")), non ho trovato nulla di
>simile ad alcune funzionalità di completamento o navigazione di Netbeans
>
se scrivi 'if' e poi premi ctrl-spazio ti offre diverse alternative  di
completamento. Naturalmente oltre all' 'if'  si puo' farlo su molte
altre keywords ed inoltre puoi aggiugere propri template sotto
preferences -> java -> templates.

>(tipo l'utilissimo ctrl-k che completa la parola che si sta digitando con la
>parola precedente che comincia nello stesso modo,
>
sempre con ctrl-spazio

> o alt-g che salta al
>codice sorgente del metodo o della classe sotto il cursore,
>
pop-up 'open declaration'

> o ancora alt-k
>che consente di "tornare indietro" da un salto di questo tipo).
>
basta selezionare il tab del file aperto

> Salta poi
>subito agli occhi che alcune cose sono implementate maluccio, come il box
>che si apre e mostra il javadoc delle classi di cui si sta facendo il
>completamento automatico (in Eclipse tronca il testo dopo un certo punto,
>non ci sono scrollbar e non è navigabile, cose che invece sono vere in
>Netbeans 3.4).
>
effettivamente sarebbe comodo. Non so se lo sai ma nel sito di eclipse
puoi richiedere nuove funzionalità che, ho avuto prova, sono lette e
prese in considerazione.

>Devo dire poi che ho trovato interessanti le obiezioni che
>sono state fatte all'unanime coro pro-eclipse da un altro fan di Netbeans su
>theserverside.com (nel thread
>http://www.theserverside.com/home/thread.jsp?thread_id=14251 che è oramai
>decisamente nutrito di commenti, che generalmente tendono a consigliare
>intellij IDEA contro ad Eclipse).
>
>Saluti,
>Davide Baroncelli.
>
>
>
>To unsubscribe from this group, send an email to:
>extremeprogramming-it-unsubscribe@egroups.com
>
>
>
>L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle
http://it.docs.yahoo.com/info/utos.html
>
>
>
>
>
Ciao

Giannandrea

Paolo Polce wrote:

> Hello marco_unirel,
>
> Monday, July 8, 2002, 1:35:12 PM, you wrote:
>
> m> Le caratteristiche del progetto attuale ci hanno portato a scrivere
> m> eseguibili "mock"  nativi che vengono lanciati da Java.
> m> --Marco Dani, Luigi Mengoni (Team Pongo)
>
> Non sono sicuro di aver capito che intendete per mock nativi. Sono
> oggetti c/c++ lanciati da jni?
> Vi spiace farmi un esempio?
> Mi interessa sapere i diversi tipi di mock
> che i vari programmatori usano.

Per quanto riguarda noi puoi dare un occhio al paper che abbiamo presentato al
workshop sul testing di
XP2002 (http://www.cwi.nl/events/2002/wtixp/papers/Bossi.pdf). All'inizio
usavamo dei mock objects con
valori picconati, poi ci siamo resi conto che era più comodo programmare
esplicitamente i mock object
direttamente nel test e solo per ciò che si rende necessario nel test stesso.
Ciò aumenta notevolmente
la leggibilità del test stesso.

Oggi usiamo i mock objects con un atteggiamento un po' ambivalente. Ne facciamo
un uso abbastanza
significativo sugli strati dove c'è paradigm crossing (gui, database, servlet),
mentre per il resto
tendiamo a evitare di usarli e preferiamo lasciar interagire gli oggetti reali.
Non usiamo framework
particolari di mock objects, probabilmente come i ponghi, però devo dire che in
questo VAJ ci limita
molto (per il supporto limitato di reflection proprio del jdk 1.2.2).

Btw, concedimi una piccola punzecchiatura: al workshop c'erano anche Mackinnon e
Freeman, che immagino
tu conosca bene :-) però non mi sono sembrati molto entusiasti e recettivi delle
nostre idee come di
quelle di tanti altri...

Ciao, Giuliano


PS: "noi" = XPlayers