Francesco Cirillo wrote:

> Considerato il feedback finora espresso, proviamo ad organizzare una chat il
> prossimo martedi' alle 14.00.

Bene. Oggi ho un problema e forse non ci potrò essere prima delle 14:30 od
oltre, ma sono sicuro che
altri componenti del team XPlayers saranno presenti.

> Ovviamente manteniamo l'appuntamento della chat settimanale del martedi' alle
> 21.30.

Mmmmm, stasera? Io mi sa che passerò la palla ...

Ciao, Giuliano

Ciao,

desideriamo farti sapere che, nella sezione File del gruppo
extremeprogramming-it, troverai un nuovo file appena caricato.

   File :        /xp-it chat 01-10-02.html
   Caricato da : varvello <varvello@...>
   Descrizione : Log chat 29-01-02

Puoi accedere al file dal seguente indirizzo:
http://it.groups.yahoo.com/group/extremeprogramming-it/files/xp-it%20chat%2001-1\
0-02.html

Per ulteriori informazioni su come condividere i file con gli altri
iscritti al tuo gruppo, vai invece alla sezione di Aiuto al seguente
indirizzo:
http://help.yahoo.com/help/it/groups/files


Cordiali saluti,

varvello <varvello@...>

--- In extremeprogramming-it@y..., Piergiuliano Bossi <P.Bossi@q...>
ha scritto:
> > Ci ha colpito il fatto che in 4 giorni siate riusciti a stimare
> > efficacemente lo sforzo di 4 mesi. Abbiamo alcune domande:
>
> Colpito bene o colpito male? :-)
> Intendo: vi sembra un tempo buono, troppo breve per suggerire un
risultato affidabile, troppo lungo?

A noi sembra un tempo buono. Facciamo questa valutazione tenendo conto
che i nostri Iteration Plan per iterazioni lunghe una settimana durano
mediamente 4-5 pomodori.

> *) se è un po' più complessa, ma non troppo, elenchiamo
esplicitamente i task per renderci conto di
> cosa c'è da fare, ma non li stimiamo singolarmente, cioè continuiamo
a dare direttamente una stima per
> la storia stessa

Dal momento che avete gia' i task non converrebbe stimarli per avere
una stima piu' precisa della storia? Noi partiamo dalla stima dei task
in quanto ci siamo resi conto che piu' le carte sono piccole meglio
riusciamo a stimare. Due aspetti:
*) siamo un po' lenti nell'individuare e spezzare i task
*) ci siamo resi conto che task con stima superiore ai 5 pomodori
indicavano incertezza sulla complessita' del task. Questo ci ha
portato a preferire di spezzare laddove possibile.

> *) se invece ci sembra complessa, individuiamo quei macro
engineering task che la compongono sotto
> forma di "carte tecniche", dettagliamo ognuno di essi in normali
engineering task e lo stimiamo come
> se fosse una user story ==> alla fine la stima della user story è
data dalla somma delle stime delle
> carte tecniche
>
Che cosa intendi per carta tecnica? Non sono tutti i task per loro
natura tecnici?

--Luigi Mengoni Marco Dani (team Pongo)

Perdonatemi il forward corposo, ma a me è piaciuto un sacco! :-)

Ciao, Giuliano

Extremists:

For many endeavors, there is a hard way and an easy way. Let's pretend we
have two algorithms, one called Hard and the other Easy. Both of them
represent the cost to add each input element to a system of elements. Over
a small number of input elements, the energy required to do it the Easy way
and the Hard way might look like this:

(Fixed-width font alert)

  e = Easy
  h = Hard

  ^
  |    e
  e   e
  n  e
  e  e
  r             hhh
  g         hhhh
  y  hhhhhhh

     input elements-->

What's that you say, the alegedly Easy way looks like it takes much more
energy than the Hard way? Maybe this Easy way is just sophistry to burden
us!

If we add an order of magnitude more input elements and chart how much
energy each one requires, we get this chart:

  ^            h    eeeeeeee
  |         ee h eee
  e      eee  h
  n    ee     h
  e   e      h
  r  e      h
  g       hh
  y  hhhhh

     10s of input elements-->

The Easy way required significant input energy for the first dozen items.
But then the amount of energy required to add each item became asymptotic
to a line with a very low slope.

The Hard way, however, reaches an early limit in which the amount of energy
required to add each item doubles over the previous item. The scaling
profile is exponential.

This is why one must apply discipline when distinguishing the difference
between Hard and Easy algorithms. The Hard ones may often look easy when
rated over a small sample of input elements. And the Easy ones may be very
hard to bootstrap (and very hard to explain). But for a non-trivial number
of input elements, they are the only way to go.

--
   Phlip
          http://www.c2.com/cgi/wiki?RatAndTuyen
   --  Bad nanoprobe! Bad!  --

To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Ron Jeffries sez:

> Phlip wrote:

> > This is why one must apply discipline when distinguishing the difference
> > between Hard and Easy algorithms. The Hard ones may often look easy when
> > rated over a small sample of input elements. And the Easy ones may be
> > very hard to bootstrap (and very hard to explain). But for a non-trivial
> > number of input elements, they are the only way to go.
>
> I'd love to see this article followed up with a concrete example. (Of
> the kind you actually had in mind when you wrote the article. My
> metaphor radar was beeping a bit as I read it.)

The concrete example is alleged to be the difference between calculating
Leibniz integrals (Easy) and calculating Newton integrals (Hard). I
understand that to the west of England (where some council of landed gentry
decided Newton was better because he was English), they teach Leibniz
integrals in 5th grade.

This is anecdotal; I suspect Math is a democracy. So, as far as I was not
educated in continental Europe, I decline to go in the cargo-cult direction
here ;-)

I'l research a concrete example. Besides the obvious one, BDUF (Hard) vs TDD
(Easy).

--
   Phlip
        http://www.greencheese.org/LucidScheming
   --  Founding member of NuGWa -
         Nudists for Global Warming  --

To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--- In extremeprogramming@y..., Phlip <pplumlee@o...> wrote:
> Ron Jeffries sez:
>
> > Phlip wrote:
>
> > > This is why one must apply discipline when distinguishing the difference
> > > between Hard and Easy algorithms. The Hard ones may often look easy when
> > > rated over a small sample of input elements. And the Easy ones may be
> > > very hard to bootstrap (and very hard to explain). But for a non-trivial
> > > number of input elements, they are the only way to go.
> >
> > I'd love to see this article followed up with a concrete example. (Of
> > the kind you actually had in mind when you wrote the article. My
> > metaphor radar was beeping a bit as I read it.)
>
> The concrete example is alleged to be the difference between calculating
> Leibniz integrals (Easy) and calculating Newton integrals (Hard). I
> understand that to the west of England (where some council of landed gentry
> decided Newton was better because he was English), they teach Leibniz
> integrals in 5th grade.
>
> This is anecdotal; I suspect Math is a democracy. So, as far as I was not
> educated in continental Europe, I decline to go in the cargo-cult direction
> here ;-)
>
> I'l research a concrete example. Besides the obvious one, BDUF (Hard) vs TDD
> (Easy).

Isn't this simply a case of knowing the time complexity of the algorithm? For a
hypothetical case, there's a vast difference in time complexity between an
insertion sort (O(n**2)) and quicksort (O(log(n)). And there are even faster
methods (O(n * k)) for large n. As a rule of thumb, the breakpoint is around 10
elements.

DTSTTCPW suggests that you implement the simple algorithm first. If performance
suffers (or if analysis demonstrates that performance will suffer under the
business assumptions) then you can implement the more complex (but faster on the
actual data) algorithm later.

John Roth


> --
>   Phlip
>        http://www.greencheese.org/LucidScheming
>   --  Founding member of NuGWa -
>         Nudists for Global Warming  --


To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

A volte la cosa + semplice si situa a un livello di astrazione alto, altre volte invece a un livello di astrazione più basso, non metterei dei rigidi paletti.
In ogni caso, condivido quanto detto da chi affermava che partendo dal basso è possibile fare delle cose inutili.

Non significa forse questo essere pilotati dalle necessità?

Volo via!
Ciao, Giuliano

Ernesto Di Blasio wrote:

 

ho letto con interesse la chat...
aggiungo alla discussione alcune osservazioni:

Ci potrebbero essere le misure che 'oggettivamente' verifichino che un approccio top-down è migliore di uno che parte dal basso? ......mi spiego meglio! Forse la questione posta da Bruno non è tanto top-down sì, top-down no, ma che cosa inizio a sviluppare? Ho una guida per questo? a me accade spesso ;-)
Avere una guida 'non deterministica' credo sia proprio di un approccio evolutivo, però è difficile da seguire perchè è meno definita.
Ad esempio, il concetto di comportamenti necessari è accattivante, però mi resta un pò difficile da capire.

ciao
ernesto
 >From: extremeprogramming-it@yahoogroups.com
>Reply-To: extremeprogramming-it@yahoogroups.com
>To: extremeprogramming-it@yahoogroups.com
>Subject: [xp-it] Digest Number 281
>Date: 2 Oct 2002 11:45:47 -0000
>
>To unsubscribe from this group, send an email to:
>extremeprogramming-it-unsubscribe@egroups.com
>
>
>------------------------------------------------------------------------
>
>Questo numero contiene 1 messaggio.
>
>Argomenti in questa selezione:
>
> 1. New file uploaded to extremeprogramming-it
> Da: extremeprogramming-it
>
>
>________________________________________________________________________
>________________________________________________________________________
>
>Messaggio: 1
> Data: 1 Oct 2002 14:01:10 -0000
> Da: extremeprogramming-it
> Oggetto: New file uploaded to extremeprogramming-it
>
>
>Ciao,
>
>desideriamo farti sapere che, nella sezione File del gruppo
>extremeprogramming-it, troverai un nuovo file appena caricato.
>
> File : /xp-it chat 01-10-02.html
> Caricato da : varvello 
> Descrizione : Log chat 29-01-02
>
>Puoi accedere al file dal seguente indirizzo:
>http://it.groups.yahoo.com/group/extremeprogramming-it/files/xp-it%20chat%2001-10-02.html
>
>Per ulteriori informazioni su come condividere i file con gli altri
>iscritti al tuo gruppo, vai invece alla sezione di Aiuto al seguente
>indirizzo:
>http://help.yahoo.com/help/it/groups/files
>
>
>Cordiali saluti,
>
>varvello 
>
>
>
>
>
>
>
>
>________________________________________________________________________
>________________________________________________________________________
>
>
>
>L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle http://it.docs.yahoo.com/info/utos.html

---

MSN Foto è il sistema più facile per condividere e stampare foto online: Fai clic qui

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!

Ciao a tutti!

Martedi pomeriggio abbiamo provato a usare l'applet di Yahoo per la
chat usando sia Netscape su Linux/windows che Explorer.Non siamo
riusciti a entrare; si sono verificati due scenari:
1) non vedevamo l'applet
2) lo vedevamo ma non vedevamo ne' i partecipanti, ne' i messaggi
inclusi i nostri.

Chi riesce a fare la chat potrebbe darci un'indicazione su:
a) Sistema operativo
b) Browser
c) Cosa si deve abilitare/disabilitare
d) Ci sono problemi se siamo oltre un firewall?

Abbiamo aperto una pagina wiki su extremeprogramming:
http://www.extremeprogramming.it/cgi-lib/wiki.cgi?
ComeFarFunzionareLAppletChat

Saluti.
--Marco Dani Luigi Mengoni (Team Pongo)

Qualcosa ho scritto. Cmq in sintesi il mio consiglio è: usate IE sotto Win
disabilitando il plugin

Ciao, Giuliano

marco_unirel wrote:

> Ciao a tutti!
>
> Martedi pomeriggio abbiamo provato a usare l'applet di Yahoo per la
> chat usando sia Netscape su Linux/windows che Explorer.Non siamo
> riusciti a entrare; si sono verificati due scenari:
> 1) non vedevamo l'applet
> 2) lo vedevamo ma non vedevamo ne' i partecipanti, ne' i messaggi
> inclusi i nostri.
>
> Chi riesce a fare la chat potrebbe darci un'indicazione su:
> a) Sistema operativo
> b) Browser
> c) Cosa si deve abilitare/disabilitare
> d) Ci sono problemi se siamo oltre un firewall?
>
> Abbiamo aperto una pagina wiki su extremeprogramming:
> http://www.extremeprogramming.it/cgi-lib/wiki.cgi?
> ComeFarFunzionareLAppletChat
>
> Saluti.
> --Marco Dani Luigi Mengoni (Team Pongo)
>
> 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

marco_unirel wrote:

> A noi sembra un tempo buono. Facciamo questa valutazione tenendo conto
> che i nostri Iteration Plan per iterazioni lunghe una settimana durano
> mediamente 4-5 pomodori.

Aspetta, io non stavo parlando di iteration plan, ma solo di stima (o ristima).
Gli iteration plan poi
sono a parte, ma per tutte le 26 iterazioni sono sempre durati 1 pomodoro
(tranne un caso in cui
invece ce ne sono voluti 4, ma oggi non saprei dirti come mai, mi sa che abbiamo
fatto un grosso
lavoro di "infila questa storia", "no, poi quell'altra non riesco più ad avere
il tempo x farla" +
split e altro).

Una tipica ristima x un'iterazione di 1 o 2 settimane ci ha richiesto da un
minimo di 2 a un massimo
di 8 pomodori (con una media attorno ai 4-5 pomodori). Per cui mi sembra che i
nostri risultati siano
assolutamente congruenti. Nel post precedente parlavo di stima necessaria se
vuoi per preparare un
release plan da 0 (o poco più). In quel caso necessariamente gli estimates sono
meno dettagliati dei
riestimate a ogni iterazione. Ciò nonostante riesci a essere comunque abbastanza
preciso, a volte
addirittura meglio: in sede di ristima ante-iteration plan può ad esempio
capitare di sottostimare
certe complessità x eccesso di confidenza, ma non solo. Diciamo che ci sarebbe
da discutere per giorni
e giorni sugli aspetti psicologici che portano a influenzare la stima nelle
diverse condizioni in cui
avviene. Se vuoi startiamo un thread! :-)

> Dal momento che avete gia' i task non converrebbe stimarli per avere
> una stima piu' precisa della storia?

A volte sì, ma non sempre. Ci sono dei casi in cui la complessità di una carta
non è ben
caratterizzata dalla somma delle stime sui task che sei riuscito a evidenziare.
Se vuoi è una
riedizione della vecchia disputa tra olismo e riduzionismo: non sempre il tutto
è dato dalla somma
delle parti.

I motivi possono essere molteplici:
*) non hai individuato tutti i task
*) una caratterizzazione troppo dettagliata dei task potrebbe portarti a fare di
fatto una sorta di
design ex-ante
*) la stima si focalizza troppo sul dettaglio e poco sulle interazioni

In questi casi cerchiamo di adottare un approccio che io descrivo così: è come
trovarsi all'imbrunire,
in una stanza che non conosci, priva di illuminazione artificiale e avere la
congiuntivite (io ho
provato e ti assicuro che è così) ==> la luce è comunque troppa x i tuoi poveri
occhi martirizzati,
quindi sei costretto a strizzare le palpebre e riesci a percepire solo l'essenza
delle forme di ciò
che ti circonda. Questo è abbastanza x orientarti e riuscire a non farti male,
focalizzarti sui
dettagli sforzerebbe la tua vista (procurandoti dolore) o richiederebbe più luce
(procurandoti dolore
e comunque accecandoti). E' abbastanza x lo scopo di muoverti e non farti male.

Ora, non consiglierei sempre questo approccio, ma a volte ha funzionato. La
prima reazione del team
quando l'ho descritto è stata: "ok, vuoi che spariamo numeri a caso!" :-)
Naturalmente non è così. Forse oggi loro stessi potranno raccontarti meglio la
loro esperienza e come
hanno affrontato questi casi.

> Noi partiamo dalla stima dei task
> in quanto ci siamo resi conto che piu' le carte sono piccole meglio
> riusciamo a stimare.

Certo, confermo!
Infatti quando poi le carte sono più complesse la stima di ogni singolo task
diventa fondamentale x
arrivare alla stima complessiva della carta.

A sensazione direi:
*) carta semplice <= 10 pomodori
*) 10 pomodori <= carta media <= 30 pomodori
*) carta complessa >= 30 pomodori
Da prendere naturalmente solo come ordine di grandezza.

> Due aspetti:
> *) siamo un po' lenti nell'individuare e spezzare i task

Anche noi. Non sempre è facile. A volte quando individuiamo i task poi arriviamo
a una situazione che
non ci soddisfa e quindi lo rifacciamo da zero.

> *) ci siamo resi conto che task con stima superiore ai 5 pomodori
> indicavano incertezza sulla complessita' del task. Questo ci ha
> portato a preferire di spezzare laddove possibile.

Interessante. Così facendo avete abbassato l'errore di stima? Potete parlarci
del vostro errore di
stima?

> Che cosa intendi per carta tecnica?

Carta tecnica = task scritto su una carta

> Non sono tutti i task per loro
> natura tecnici?

Certo, solo che a volte non li scriviamo su carte a sè stanti, ma sul retro
della user story.
Le carte tecniche sono chiamate così x distinguerle dalle user story (cioè non
sono pianificabili
singolarmente, perchè in quanto tecniche non consegnano individualmente valore
al cliente).

Ciao, Giuliano

>d) Ci sono problemi se siamo oltre un firewall?
>
Tipicamente non funziona :-), sempre se nel frattempo non l'hanno cambiata
(apriva un socket su una porta specifica)

Per il resto, anche io confermo IE + VM microsozz

Ciao,

     Bruno.

| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

Quoting Ernesto Di Blasio <edibla@...>:
> <P>ho letto con interesse la chat...<BR>aggiungo alla discussione alcune
> osservazioni:</P>
> <P>Ci potrebbero essere le misure che 'oggettivamente' verifichino che
> un approccio top-down è migliore di uno che parte dal
> basso?

Non penso che il problema sia ben posto in termini di top-down, bottom-up. La
citazione di Kent fatta da Davide, mi sembra piu' corretta.

 ......mi spiego meglio! Forse la questione posta da Bruno
> non è tanto top-down sì, top-down no, ma che cosa inizio a sviluppare?

Ho una user story da realizzare, da dove inizio?!

> Ho una guida per questo? a me accade spesso ;-)<BR>Avere una guida 'non
> deterministica' credo sia proprio di un approccio evolutivo, però è
> difficile da seguire perchè è meno definita.<BR>

Hai ragione, non esiste che io sappia una guida "oggettiva" (lo intendo nel
senso di automatizzabile). Cerca Tu questa guida, e lavora per definirla (e' il
passaggio da arte a scienza descritto da Knuth).

La semplicita' puo' aiutarti una volta partito (= scritto il test), ma quale
test scrivere per prima? in base a cosa? La risposta dovrebbe essere nel
comportamento che il tuo sistema ti richiede di implementare. Per realizzare
quello ti troverai di fronte ad altri comportamenti richiesti, ma mancanti,
modificando questi potrai dover modificare altri comportamenti preesistenti o
quelli appena aggiunti. In qualche modo devi "insegnare" al sistema a chiedere
i comportamenti di cui ha bisogno.

> Ad esempio, il concetto
> di comportamenti necessari è accattivante, però mi resta un pò difficile
> da capire.

Ci sto lavorando. Mi sarebbe utile sapere in cosa ti risulta difficile da
capire. (Grazie del feedback!).

--Francesco

> > Dal momento che avete gia' i task non converrebbe stimarli per avere
> > una stima piu' precisa della storia?
>
> A volte sì, ma non sempre. Ci sono dei casi in cui la complessità di una
> carta non è ben
> caratterizzata dalla somma delle stime sui task che sei riuscito a
> evidenziare. Se vuoi è una
> riedizione della vecchia disputa tra olismo e riduzionismo: non sempre
> il tutto è dato dalla somma
> delle parti.

In ingegneria del software tradizionale per arrivare ad una stima accurata si
procede con una macrostima - basata in genere sulle funzionalta' - e una
microstima - in cui si effettua la WBS (si scompongono i task), si stimano i
singoli task e li si somma. In genere una stima realistica si trova all'interno
di queste due valutazioni di sforzo. Migliore la capacita' di stima, minore la
forbice tra le due stime.

A mio modo di vedere stimare sulle user story (=senza considerare task)
rappresenta una forma di macrostima estremamente importante. Risulta
fondamentale ad esempio nel planning game. La stima basata sui task richiede
troppo tempo per essere eseguita. Nel planning game invece il cliente va
supportato con stime ragionate, ma immediate, per le nuove user story che il
cliente voglia aggiungere. La stima delle user story risulta ovviamente piu'
agevole di qualla per uno use case per questioni di "massa" di funzionalita' da
considerare.

L'esperienza, lo splitting delle user story _ad_opera_del_cliente_ e il
continuo accostamento delle stime sulle user story con le stime sui task, con i
dati reali di progetto, portano a ridurre la suddetta forbice, supportando lo
sviluppo del business del cliente.

> In questi casi cerchiamo di adottare un approccio che io descrivo così:
> è come trovarsi all'imbrunire, in una stanza che non conosci, priva di
> illuminazione artificiale e avere la congiuntivite (io ho
> provato e ti assicuro che è così) ==> la luce è comunque troppa x i tuoi
> poveri occhi martirizzati, quindi sei costretto a strizzare le palpebre e
> riesci a percepire solo l'essenza delle forme di ciò che ti circonda. Questo
> è abbastanza x orientarti e riuscire a non farti male, focalizzarti sui
> dettagli sforzerebbe la tua vista (procurandoti dolore) o richiederebbe
> più luce (procurandoti dolore e comunque accecandoti). E' abbastanza x lo
> scopo di muoverti e non farti male.

OK. Spero a breve di riuscire a trovare un esempio meno cruento da usare come
metafora. :)

Una nota... le user story vengono splittate dal cliente e non dagli
sviluppatori. Gli sviluppatori hanno tutto il diritto di dire che una carta non
e' stimabile (una user story presa come elemento atomico oggetto di stima puo'
non essere stimabile - qualsiasi user story, funzionalita', e' sempre stimabile
attraverso una microstima), ma e' il cliente a decidere come splittarla e
definirne i test.

--Francesco

Un po' di feedback sulla chat delle 14.00.

Mi e' piaciuto molto "incontrare" diversi di voi. L'orario mi sembra ideale, ma
va limitato. Come giustamente notava Bruno in chat si dovrebbe arrivare tra le
13.45 e le 14.00. Alle 14.45 si dovrebbe iniziare a chiedere i feedback di
chiusura. Gli argomenti per la chat dovrebbero essere raccolti durante la
settimana in un'apposita pagina del wiki. Eventuali esempi a supporto
dovrebbero essere forniti per tempo sempre sul wiki. In questo modo si avrebbe
il tempo per metabolizzare il tema di discussione, farsi una idea e proporla
durante la chat.

Siamo in tanti. Ricordo le poche semplici "regole" che ci siamo dati nel
passato:
- usare i puntini sospensivi (...) al termine della riga per indicare che non
si e' terminato il pensiero. Es. >francesco: le user story in ...
- usare il carattere pipe (|) per indicare la fine del pensiero. Es.
>francesco: XP sono ancora un mistero per me! |
- Non si interviene fino a che chi scrive non termina il pensiero con un
carattere |.

Stimolo inoltre tutti a dotarsi di microfono e cuffia. L'anno scorso facemmo
delle chat audio e non erano affatto male.

Quanto alla chat serale, Ernesto, la prossima volta mandami un messaggio
di "sveglia" (un messaggio personale fa uscire una popup). Ero anche io li' che
aspettavo.

Aspetto il vostro feedback

--Francesco Cirillo
Director, XPLabs, S.R.L.
Coach, Bees Team
http://www.xplabs.com

<Uno stimolo a chi voleva cominciare un progetto di gruppo>

>>d) Ci sono problemi se siamo oltre un firewall?
>Tipicamente non funziona :-), sempre se nel frattempo non l'hanno cambiata
>(apriva un socket su una porta specifica)
>Per il resto, anche io confermo IE + VM microsozz

Mi sembra di intravedere delle possibili user story per una chat...

</Uno stimolo a chi voleva cominciare un progetto di gruppo>

--Francesco Cirillo
Director, XPLabs, S.R.L.
Coach, Bees Team
http://www.xplabs.com

Sorry, avrei voluto avere tempo di mettere del codice sul wiki ma sono preso
almeno fino a Martedi :-( Gia' oggi per scrivere questa email mi sono
giocato il pranzo...


>> <P>Ci potrebbero essere le misure che 'oggettivamente' verifichino che
>> un approccio top-down è migliore di uno che parte dal
>> basso?
>
>Non penso che il problema sia ben posto in termini di top-down, bottom-up.
>La citazione di Kent fatta da Davide, mi sembra piu' corretta.
>
Senza dubbio, ma capisco il problema citato da Ernesto. Molte volte ci
troviamo a dovere implementare delle funzionalita' che sono completamente
definite, sia in termini di interazione dell'utente sia in termini di
interazioni con il sistema. Da dove partire?

Quella che citavo io nella chat, ad esempio: nella sequenza di avvio della
mia applicazione client deve essere prevista una funzionalita' automatica
che preleva delle informazioni da un file ed aggiorna il database. Davide
sarebbe partito da un punto, io da un altro. Questa richiesta puo' essere
affrontata in due modi, sempre rispettando la direzione conosciuto ->
sconosciuto. Si puo' partire dal file o dal db e costruire incrementalmente
la funzionalita richiesta; si puo' partire dalla sequenza di avvio e
costruire la funzionalita' arrivando, alla fine, all'interazione con il db e
con il filesystem.

In questo periodo io mi trovo frequentemente a scegliere una direzione che
parte "dall'alto" (passatemi il termine) ovvero dal caso d'uso richiesto
dall'utente e quindi arriva "in profondita", ovvero in questo caso sul
DB/filesystem. Ma la cosa non mi convince pienamente, per i motivi che
descrivo sotto, e avrei bisogno del vostro parere.

>La semplicita' puo' aiutarti una volta partito (= scritto il test),
>ma quale  test scrivere per prima? in base a cosa? La risposta
>dovrebbe essere nel comportamento che il tuo sistema ti richiede
>di implementare. Per realizzare quello ti troverai di fronte ad
>altri comportamenti richiesti, ma mancanti, modificando questi
>potrai dover modificare altri comportamenti preesistenti o
>quelli appena aggiunti. In qualche modo devi "insegnare" al
>sistema a chiedere i comportamenti di cui ha bisogno.
>
Sottoscrivo, ed e' quello che noi cerchiamo di fare. Ma nel metodo che
usiamo noi c'e' qualcosa che francamente non ci torna, ed era questa la
questione che ho cercato di sollevare in chat.

Noi qui usiamo una metafora mutuata in parte da te :-), ovvero la quella del
cosa-come, in cui adesso che ci rifletto riconosco bene il known-unknown di
Kent. Quando scriviamo un test ci chiediamo "cosa" deve fare il sistema, e
scriviamo il test in quei termini, senza preoccuparci del "come". Fatto
girare il test, usando come "come" un implementazione mock, ci mettiamo
quindi a trattarlo come un "cosa" di nuovo definito in termini di "come".
Ehm.... confusionario, eh? Tornando all'esempio di prima, il primo "cosa"
che affronteremo sara' la modifica della sequenza di avvio (SequenzaDiAvvio)

La sequenza di avvio dovra' svolgere un certo "cosa", cioe' dovra' invocare
una logica (LogicaAggiornamento) che fa un certo come, di cui ci
disinteressiamo. Scriviamo quindi il test del cosa, passandogli una logica
mock(LogicaAggiornamentoMock), barre verdi, refactoring, finito!
   SequenzaDiAvvio 	 (modificata)
   LogicaAggiornamento 	 (nuova intefaccia)
   LogicaAggiornamentoMock  (nuova implementazione finta)

Ora ci dedichiamo al "cosa" della logica, chiamiamola
LogicaAggiornamentoReale, che deve leggere da file (un "come", quindi
un'altra logica) e scrivere su db (un altro "come", quindi un altra logica).
Scriviamo il test di passandogli due mock, ovvero ParserFileMock e
AggiornatoreDbMock, barre verdi, refactoring, finito!
   LogicaAggiornamentoReale  (nuova classe concreta)
   ParserFile 	 (nuova interfaccia)
   ParserFileMock 	 (nuova implementazione finta)
   AggiornatoreDb 	 (nuova interfaccia)
   AggiornatoreDbMock  (nuova implementazione finta)

Okay, mi fermo per ora :-). Il problema e' che le interfacce cominciano a
proliferare, ed e' veramente seccante! E' possibile che per ogni dannata
logica debba fare una dannata interfaccia? Certo, e' possibile effettuare
ulteriore refactoring e riconciliare le interfacce con altre esistenti, ma
il fatto che per testare una logica io debba fare un'interfaccia ad-hoc,
insomma, e' una vera rottura.

Dobbiamo proprio passare a Python? :-D

Ok, devo scappare, spero di avere fornito qualche spiegazione e qualche
ulteriore argomento di discussione!

Ciao,

     Bruno.

| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

>Stimolo inoltre tutti a dotarsi di microfono e cuffia. L'anno scorso
>facemmo delle chat audio e non erano affatto male.
>
Sorry, io per ora non posso, per il resto concordo. L'unica cosa che mi
frega e' il fattore tempo (non ne ho :-D)

Ciao,

     Bruno.


| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

--- Bruno Bossola <bbossola@...> wrote:
> Sorry, avrei voluto avere tempo di mettere del
> codice sul wiki ma sono preso
> almeno fino a Martedi :-( Gia' oggi per scrivere
> questa email mi sono
> giocato il pranzo...
>
>
> >> <P>Ci potrebbero essere le misure che
> 'oggettivamente' verifichino che
> >> un approccio top-down è migliore di uno che parte
> dal
> >> basso?
> >
> >Non penso che il problema sia ben posto in termini
> di top-down, bottom-up.
> >La citazione di Kent fatta da Davide, mi sembra
> piu' corretta.
> >
> Senza dubbio, ma capisco il problema citato da
> Ernesto. Molte volte ci
> troviamo a dovere implementare delle funzionalita'
> che sono completamente
> definite, sia in termini di interazione dell'utente
> sia in termini di
> interazioni con il sistema. Da dove partire?
>
> Quella che citavo io nella chat, ad esempio: nella
> sequenza di avvio della
> mia applicazione client deve essere prevista una
> funzionalita' automatica
> che preleva delle informazioni da un file ed
> aggiorna il database. Davide
> sarebbe partito da un punto, io da un altro. Questa
> richiesta puo' essere
> affrontata in due modi, sempre rispettando la
> direzione conosciuto ->
> sconosciuto. Si puo' partire dal file o dal db e
> costruire incrementalmente
> la funzionalita richiesta; si puo' partire dalla
> sequenza di avvio e
> costruire la funzionalita' arrivando, alla fine,
> all'interazione con il db e
> con il filesystem.
>
> In questo periodo io mi trovo frequentemente a
> scegliere una direzione che
> parte "dall'alto" (passatemi il termine) ovvero dal
> caso d'uso richiesto
> dall'utente e quindi arriva "in profondita", ovvero
> in questo caso sul
> DB/filesystem. Ma la cosa non mi convince
> pienamente, per i motivi che
> descrivo sotto, e avrei bisogno del vostro parere.

Ok, ora mi e' chiaro (durante la chat non avevo capito
che la tua situazione a che punto della funzionalita'
eri) e credo che anch'io sarei partito dal lato
"utente" e non dal data storage.

Riguardo invece il tuo post qui sotto, l'unica cosa
che mi viene in mente e' tentare di semplificare il
tutto, cioe' e' necessario affrontare:
LogicaAggiornamentoMock,  SequenzaDiAvvio,
LogicaAggiornamento
e
LogicaAggiornamentoReale,  ParserFile,
ParserFileMock,
AggiornatoreDb, AggiornatoreDbMock?

Non riesci a "ritardare" la nascita di tutti questi
oggetti? Perche' effettivamente c'e' un po' troppa
carne al fuoco.

bye
  Davide

> >La semplicita' puo' aiutarti una volta partito (=
> scritto il test),
> >ma quale  test scrivere per prima? in base a cosa?
> La risposta
> >dovrebbe essere nel comportamento che il tuo
> sistema ti richiede
> >di implementare. Per realizzare quello ti troverai
> di fronte ad
> >altri comportamenti richiesti, ma mancanti,
> modificando questi
> >potrai dover modificare altri comportamenti
> preesistenti o
> >quelli appena aggiunti. In qualche modo devi
> "insegnare" al
> >sistema a chiedere i comportamenti di cui ha
> bisogno.
> >
> Sottoscrivo, ed e' quello che noi cerchiamo di fare.
> Ma nel metodo che
> usiamo noi c'e' qualcosa che francamente non ci
> torna, ed era questa la
> questione che ho cercato di sollevare in chat.
>
> Noi qui usiamo una metafora mutuata in parte da te
> :-), ovvero la quella del
> cosa-come, in cui adesso che ci rifletto riconosco
> bene il known-unknown di
> Kent. Quando scriviamo un test ci chiediamo "cosa"
> deve fare il sistema, e
> scriviamo il test in quei termini, senza
> preoccuparci del "come". Fatto
> girare il test, usando come "come" un
> implementazione mock, ci mettiamo
> quindi a trattarlo come un "cosa" di nuovo definito
> in termini di "come".
> Ehm.... confusionario, eh? Tornando all'esempio di
> prima, il primo "cosa"
> che affronteremo sara' la modifica della sequenza di
> avvio (SequenzaDiAvvio)
>
> La sequenza di avvio dovra' svolgere un certo
> "cosa", cioe' dovra' invocare
> una logica (LogicaAggiornamento) che fa un certo
> come, di cui ci
> disinteressiamo. Scriviamo quindi il test del cosa,
> passandogli una logica
> mock(LogicaAggiornamentoMock), barre verdi,
> refactoring, finito!
>   SequenzaDiAvvio 	 (modificata)
>   LogicaAggiornamento 	 (nuova intefaccia)
>   LogicaAggiornamentoMock  (nuova implementazione
> finta)
>
> Ora ci dedichiamo al "cosa" della logica,
> chiamiamola
> LogicaAggiornamentoReale, che deve leggere da file
> (un "come", quindi
> un'altra logica) e scrivere su db (un altro "come",
> quindi un altra logica).
> Scriviamo il test di passandogli due mock, ovvero
> ParserFileMock e
> AggiornatoreDbMock, barre verdi, refactoring,
> finito!
>   LogicaAggiornamentoReale  (nuova classe concreta)
>   ParserFile 	 (nuova interfaccia)
>   ParserFileMock 	 (nuova implementazione finta)
>   AggiornatoreDb 	 (nuova interfaccia)
>   AggiornatoreDbMock  (nuova implementazione finta)
>
> Okay, mi fermo per ora :-). Il problema e' che le
> interfacce cominciano a
> proliferare, ed e' veramente seccante! E' possibile
> che per ogni dannata
> logica debba fare una dannata interfaccia? Certo, e'
> possibile effettuare
> ulteriore refactoring e riconciliare le interfacce
> con altre esistenti, ma
> il fatto che per testare una logica io debba fare
> un'interfaccia ad-hoc,
> insomma, e' una vera rottura.
>
> Dobbiamo proprio passare a Python? :-D
>
> Ok, devo scappare, spero di avere fornito qualche
> spiegazione e qualche
> ulteriore argomento di discussione!
>
> Ciao,
>
>     Bruno.
>
> | Bruno Bossola
> | CSP SpA - www.cspnet.it
> | Responsabile area Sistemi Distribuiti
>
>
>
>
> 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
>
>


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

>Non riesci a "ritardare" la nascita di tutti questi
>oggetti? Perche' effettivamente c'e' un po' troppa
>carne al fuoco.
>
Non mi sono spiegato bene, non e' questo il problema, gli oggetti nascono
ovviamente nel momento in cui ne ho bisogno. Mentre scrivo i "cosa"
(interfacce) non penso ai "come" (implementazioni) che per me sono
ortogonali, e che saranno realizzati successivamente.

In ogni momento sto lavorando solo su un cosa, ma...
>> ... il problema e' che le interfacce cominciano a
>> proliferare, ed e' veramente seccante...
>>

Comunque per chiarezza facciamo tutta la storia (ah, e' ovvio che parto dai
test e poi faccio refactoring, per comodita' mi limito ad indicare gli
oggetti)

1) Modifico la sequenza di avvio in modo da includere la nuova logica
SequenzaDiAvvio (modificata)
LogicaAggiornamento (nuova intefaccia)
LogicaAggiornamentoMock (nuova implementazione finta)

2) Implemento la logica di aggiornamento reale
LogicaDiAggiornamentoReale
ParserFile 		 (nuova interfaccia)
ParserFileMock 	 (nuova implementazione finta)
AggiornatoreDb 	 (nuova interfaccia)
AggiornatoreDbMock  (nuova implementazione finta)

3) Implemento la il perser del file
ParserFileReale
(uso di mock preesistenti)

4) Implemento l'aggiornatore reale
AggiornatoreDbReale
(uso di mock preesistenti)

Scrivere un mock (specialmente se usate mockobjects) e' dannatamente rapido,
e non ci sono grossi problemi. Cio' che mi rompe e' scrivere tutte quelle
interfacce che in fondo non servono a un tubo, sono un rinforzo sintattico
ad una funzione che e' testata. A che servono? Non si possono eliminare? A
me rompono, occupano spazio, irrigidiscono quando devo rifattorizzare o
riassegnare le logiche, sono sicuro che in SmallTalk e' tutto + semplice (e
anche in Python, da qui la citazione).

Tutte queste interfacce, che nascono per esigenza di test, rendono il codice
rigido, scarsamente malleabile. Non possiamo disfarcene? Saro' piu'
estremo... non possiamo ereditare da Object e usare _quella_ interfaccia e
basta?

Per la precisione, io mi sono fatto un simpatico metodo nella mia classe di
test, invoke(), che consente di invocare un servizio di un oggetto via
reflection... e funziona alla grande! In questo modo posso (potrei) buttare
nel cesso tutte le interfacce.

Il problema e'.... la strada che sto percorrendo e' corretta? Non sto
"violentando" il linguaggio? Sto semplicemente rifattorizzando troppo poco o
nel modo sbagliato?


Ciao,

     Bruno.


| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

> Non mi sono spiegato bene, non e' questo il problema, gli oggetti
> nascono ovviamente nel momento in cui ne ho bisogno. Mentre scrivo i "cosa"
> (interfacce) non penso ai "come" (implementazioni) che per me sono
> ortogonali, e che saranno realizzati successivamente.

Per me cosa = test, non le interfacce.

> In ogni momento sto lavorando solo su un cosa, ma...
> >> ... il problema e' che le interfacce cominciano a
> >> proliferare, ed e' veramente seccante...
> Comunque per chiarezza facciamo tutta la storia (ah, e' ovvio che parto
> dai test e poi faccio refactoring, per comodita' mi limito ad indicare gli
> oggetti)
> 1) Modifico la sequenza di avvio in modo da includere la nuova logica
> SequenzaDiAvvio (modificata)
> LogicaAggiornamento (nuova intefaccia)
> LogicaAggiornamentoMock (nuova implementazione finta)
> 2) Implemento la logica di aggiornamento reale
> LogicaDiAggiornamentoReale
> ParserFile 		 (nuova interfaccia)
> ParserFileMock 	 (nuova implementazione finta)
> AggiornatoreDb 	 (nuova interfaccia)
> AggiornatoreDbMock  (nuova implementazione finta)
> 3) Implemento la il perser del file
> ParserFileReale
> (uso di mock preesistenti)
> 4) Implemento l'aggiornatore reale
> AggiornatoreDbReale
> (uso di mock preesistenti)
> Scrivere un mock (specialmente se usate mockobjects) e' dannatamente
> rapido,
> e non ci sono grossi problemi. Cio' che mi rompe e' scrivere tutte
> quelle
> interfacce che in fondo non servono a un tubo, sono un rinforzo
> sintattico
> ad una funzione che e' testata.

Personalmente, oltre alle interfacce non condivido neanche l'uso di tutti quei
mock. (forse mi sfugge qualcosa?!). Sembra quasi che automaticamente
implementare una logica voglia dire creare una interfaccia e un mock. Condivido
l'uso di mock per specifiche questioni, non condivido un uso generalizzato anzi
sistematico, almeno da come mi sembri proporlo. L'unico effetto sicuro di una
pratica del genere e' aumentare la complessita'.

Al momento sto lavorando su un sistema di content management. In una settimana
il sistema e' cresciuto a 150 classi, nessuna interfaccia e nessun mock object.

> A che servono? Non si possono eliminare?
> A me rompono, occupano spazio, irrigidiscono quando devo rifattorizzare
> o riassegnare le logiche, sono sicuro che in SmallTalk e' tutto + semplice
> (e anche in Python, da qui la citazione).

In Smalltalk le interfacce non sono necessarie.

Eliminale. Prova, e vedi se puoi farne a meno.

> Tutte queste interfacce, che nascono per esigenza di test, rendono il
> codice rigido, scarsamente malleabile. Non possiamo disfarcene?

Prova!

> Saro' piu'
> estremo... non possiamo ereditare da Object e usare _quella_ interfaccia
> e basta?
> Per la precisione, io mi sono fatto un simpatico metodo nella mia classe
> di test, invoke(), che consente di invocare un servizio di un oggetto via
> reflection... e funziona alla grande! In questo modo posso (potrei)
> buttare nel cesso tutte le interfacce.

Anche io partii con qualcosa del genere. Poi vuoi togliere le parentesi, i
punti e virgola, etc etc. Conosco il processo :).

Il linguaggio e' uno strumento. Se riesci a cambiarlo e a ottenere maggiore
comunicativita', o maggiore efficacia nel cambiamento...

(Attento: sei sulla buona strada per arrivare a chiederti - Perche' programmo
in Java...)

> Il problema e'.... la strada che sto percorrendo e' corretta? Non sto
> "violentando" il linguaggio? Sto semplicemente rifattorizzando troppo
> poco o nel modo sbagliato?

Il linguaggio e' uno strumento. La tua capacita' e' nel valutare se i
cambiamenti che apporti vanno nella direzione di aumentare la comunicativita' e
semplificare il cambiamento (=+malleabilita').

Consiglio. Prova a far vedere come usi il tuo oggetto con invoke(). Solita
pagina di wiki, please...

Francesco

In XPLabs sto cercando di organizzare un calendario di seminari gratuiti su XP.

L'idea e' di offrire un seminario al mese su tematiche relative a XP.

I seminari si terrebbero presso il nostro centro di Sutri (VT) o - piu' in la' -
presso la nostra nuova sede corsi di Roma.

Prima di impegnare gli speaker (nella mia idea nazionali e internazionali),
vorrei avere una idea della possibile affluenza a questi seminari e degli
argomenti che si vorrebbe fossero trattati. Possibili preferenze, indicazioni,
suggerimenti, di qualsiasi tipo sono ultra-bene accette. In particolare sono
particolarmente apprezzate indicazioni del tipo, giorno della settimana e
orario migliore per fissare i seminari.

Mi date una mano?

Mandate il vostro feedback direttamente al mio indirizzo:
francesco.cirillo@...

--Francesco Cirillo
Director, XPLabs, S.R.L.
Coach, Bees Team
http://www.xplabs.com

P.S. Se volete proporre un seminario, scrivete al mio indirizzo di email.

>Per me cosa = test, non le interfacce.
>
Per me "cosa" = funzionalita', espressa in termini di servizi, che in java
sono metodi dichiarati implicitamente nella definizione di una classe e
esplicitamente con un'interfaccia; invece "come" costituise l'internalities
dell'implementazione. E' piu' chiaro?

Ovviamente, come gia' detto, ciascun "cosa" ha un test che ne richiede
l'esistenza e ne verifica il corretto funzionamento.


>Personalmente, oltre alle interfacce non condivido neanche l'uso di tutti
>quei mock. (forse mi sfugge qualcosa?!). Sembra quasi che automaticamente
>implementare una logica voglia dire creare una interfaccia e un mock.
>Condivido l'uso di mock per specifiche questioni, non condivido un uso
>generalizzato anzi sistematico, almeno da come mi sembri proporlo.
>
Non c'e' questa sistematicita', ma effettivamente nel caso di
implementazione di una logica che coordina altre logiche (come nel caso di
questa LogicaAggiornamento) usiamo mock (e interfacce, poiche' richiesto da
java) per simulare le logiche coordinate e verificare quindi che l'azione di
coordinamento sia corretta.

Rimanendo sempre nell'ambito di questo esempio, qualcuno puo' mostrarmi un
modo alternativo per la realizzazione?


>L'unico effetto sicuro di una pratica del genere e' aumentare la
>complessita'.
>
Questo in effetti e' il problema che mi affligge...


>Al momento sto lavorando su un sistema di content management. In una
>settimana il sistema e' cresciuto a 150 classi, nessuna interfaccia e
>nessun mock object.
>
Interesting! E in che linguaggio? E come testate le logiche di
coordinamento? (le equivalenti di LogicaAggiornamentoReale del mio esempio).


>Eliminale. Prova, e vedi se puoi farne a meno.
>
Purtroppo non posso a meno dell'uso del truschino, ovvero l'invocazione per
"nome" dei servizi da testare, che ancora non mi convince (o forse mi ci
vuole solo tempo?).


>Attento: sei sulla buona strada per arrivare a chiederti - Perche'
>pogrammo in Java...)
>
Effettivamente da un po' sto considerando Python...


>Consiglio. Prova a far vedere come usi il tuo oggetto con invoke().
>Solita pagina di wiki, please...
>
Ok, oggi sono incasinato con il trasloco dell'ufficio ma cerco di metterlo
per stasera.

Grazie e ciao,

     Bruno.


| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

Ciao a tutti,
in questi giorni stiamo portando su Eclipse e CVS i nostri progetti che
prima erano su VAJ.
Uno dei problemi che abbiamo avuto e' stato quello del versioning in locale.
In sintesi si tratta di trovare un modo semplice di versionare un progetto
in modo da poter tornare in dietro dopo un passo di refactoring che si
rivela sbagliato o qualcosa del genere.
Al link
http://www.extremeprogramming.it/cgi-lib/wiki.cgi?VersioningConEclipse del
wiki di xp-it trovate i dettagli.
Qualcuno ha avuto un problema simile e ha trovato soluzioni piu' semplici?

Andrea



_________________________________________________________________
MSN Foto è il sistema più facile per condividere e stampare foto online:
http://photos.msn.it

On Tue, Oct 08, 2002 at 04:37:22PM +0200, Andrea Vaccaro wrote:
> Ciao a tutti,
> in questi giorni stiamo portando su Eclipse e CVS i nostri progetti che
> prima erano su VAJ.
> Uno dei problemi che abbiamo avuto e' stato quello del versioning in locale.
> In sintesi si tratta di trovare un modo semplice di versionare un progetto
> in modo da poter tornare in dietro dopo un passo di refactoring che si
> rivela sbagliato o qualcosa del genere.
> Al link
> http://www.extremeprogramming.it/cgi-lib/wiki.cgi?VersioningConEclipse del
> wiki di xp-it trovate i dettagli.
> Qualcuno ha avuto un problema simile e ha trovato soluzioni piu' semplici?


Perché non ti astieni dal fare commit fino a quando non sei abbastanza
sicuro che le modifiche vanno bene?

In alternativa potrebbe esserti utile il comando

    cvs checkout -D DATE

che recupera la situazione alla data DATE.

Matteo

>Uno dei problemi che abbiamo avuto e' stato quello del versioning in
locale.
>In sintesi si tratta di trovare un modo semplice di versionare un progetto
>in modo da poter tornare in dietro dopo un passo di refactoring che si
>rivela sbagliato o qualcosa del genere.
>
Direi che e' sufficiente installare un CVS in locale su ciascuna macchina di
sviluppo (cvsnt, per esempio) e collegarsi a quello locale durante lo
sviluppo della candidate(*). Per l'integrazione e per il download della
baseline(**) vi collegate a quello centrale.

Penso che possiate con poche righe di codice integrarvi direttamente con il
plug-in per cvs di eclipse, in modo da gestire lo "swap" del CVS in modo
automatico. (hey, se lo fate passatelo!)

Ciao,

     Bruno.


(*) candidate: la versione candidata all'integrazione, quella su cui si
sviluppa; e' un termine che klondike ha preso dal libro rosa su XP

(*) baseline: la versione sulla macchina di integrazione, in pratica
l'ultima release / build da cui si parte a sviluppare e frutto delle
integrazioni delle candidate; e' un termine che klondike ha preso dal libro
rosa su XP


| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

Ciao,
in effetti la soluzione che proponi e' una di quelle a cui avevamo pensato
(invece di un repository CVS locale su ogni macchina abbiamo fatto piu'
repository remoti ma dovrebbe essere analogo).
Abbiamo provato prima a farlo manualmente e il punto piu' incasinato e' il
"travaso" dei file da un progetto all'altro. Il problema principale sono i
file sotto le directory CVS che vanno tenuti in sincrono (es. se un file
viene cancellato da un progetto va' aggiunto un carattere '-' al suo numero
di versione nel file CVS/Entries).
Abbiamo provato ad automatizzarlo dall'esterno di Eclipse, cioe' a spostare
i file su file-system e a sincronizzare i file CVS ma poi abbiamo pensato
che la soluzione della copia del progetto era piu' semplice e abbiamo
abbandonato l'impresa.
Forse farlo direttamente dall'interno di Eclipse potrebbe semplificare
questo aspetto ma dovremmo studiarci come si scrive un plug-in o almeno come
ci si attacca ad un plug-in esistente come quello di CVS, cosa che penso non
sia banale. Qualcuno in lista ha avuto esperienze del genere?

>From: "Bruno Bossola" <bbossola@...>
>Reply-To: extremeprogramming-it@yahoogroups.com
>To: <extremeprogramming-it@yahoogroups.com>
>Subject: RE: [xp-it] Versioning con Eclipse
>Date: Wed, 9 Oct 2002 09:03:37 +0200
>
> >Uno dei problemi che abbiamo avuto e' stato quello del versioning in
>locale.
> >In sintesi si tratta di trovare un modo semplice di versionare un
>progetto
> >in modo da poter tornare in dietro dopo un passo di refactoring che si
> >rivela sbagliato o qualcosa del genere.
> >
>Direi che e' sufficiente installare un CVS in locale su ciascuna macchina
>di
>sviluppo (cvsnt, per esempio) e collegarsi a quello locale durante lo
>sviluppo della candidate(*). Per l'integrazione e per il download della
>baseline(**) vi collegate a quello centrale.
>
>Penso che possiate con poche righe di codice integrarvi direttamente con il
>plug-in per cvs di eclipse, in modo da gestire lo "swap" del CVS in modo
>automatico. (hey, se lo fate passatelo!)
>
>Ciao,
>
>     Bruno.
>
>
>(*) candidate: la versione candidata all'integrazione, quella su cui si
>sviluppa; e' un termine che klondike ha preso dal libro rosa su XP
>
>(*) baseline: la versione sulla macchina di integrazione, in pratica
>l'ultima release / build da cui si parte a sviluppare e frutto delle
>integrazioni delle candidate; e' un termine che klondike ha preso dal libro
>rosa su XP
>
>
>| Bruno Bossola
>| CSP SpA - www.cspnet.it
>| Responsabile area Sistemi Distribuiti
>
>




_________________________________________________________________
Chiacchiera con gli amici online, prova MSN Messenger:
http://messenger.msn.it

Ciao,

>From: Matteo Vaccari <vaccari@...>
>Date: Tue, 8 Oct 2002 17:11:16 +0200
>Perché non ti astieni dal fare commit fino a quando non sei abbastanza
>sicuro che le modifiche vanno bene?
>

Questo e' quello che facciamo nel caso di una integrazione: prima
verifichiamo che passino tutti i test e poi rilasciamo una nuova versione.
Il problema si pone quando tu vuoi fare una versione per te che non vuoi
condividere con il team perche' e' solo un tentativo temporaneo, magari
perche' stai per fare una mossa di refactoring e vuoi la liberta' di poter
pasticciare quanto vuoi.
In questo caso non vorrei usare il repository visto da tutti perche'
aggiungerei solo confusione agli altri pair. Pero' al tempo stesso vorrei
fare una versione di tutto il progetto da ripristinare se qualcosa va storto
o anche solo per fare un compare e vedere se era meglio prima o adesso.

Andrea



_________________________________________________________________
MSN Hotmail è il provider email più grande al mondo… cosa aspetti a farti un
account? http://www.hotmail.it

> Il problema si pone quando tu vuoi fare una versione per te che non vuoi
> condividere con il team perche' e' solo un tentativo temporaneo, magari
> perche' stai per fare una mossa di refactoring e vuoi la liberta' di poter
> pasticciare quanto vuoi.
> In questo caso non vorrei usare il repository visto da tutti perche'
> aggiungerei solo confusione agli altri pair. Pero' al tempo stesso vorrei
> fare una versione di tutto il progetto da ripristinare se qualcosa va storto
> o anche solo per fare un compare e vedere se era meglio prima o adesso.

Allora forse potresti usare cvs checkout -D DATE; ti permette di
recuperare la situazione del progetto a un istante arbitrario; cosi'
puoi tornare alla situazione all'istante in cui hai fatto il tuo
"branch" solitario.

Matteo

>> Il problema si pone quando tu vuoi fare una versione per te che non vuoi
>> condividere con il team perche' e' solo un tentativo temporaneo, magari
>> perche' stai per fare una mossa di refactoring e vuoi la liberta' di
poter
>> pasticciare quanto vuoi.
>>
>Allora forse potresti usare cvs checkout -D DATE; ti permette di
>recuperare la situazione del progetto a un istante arbitrario; cosi'
>puoi tornare alla situazione all'istante in cui hai fatto il tuo
>"branch" solitario.
>
Pero' se tutti lavorano sullo stesso repository sarebbero ritornate delle
modifiche un po' "sparse", nel senso che non mi becco solo quello che ho
forkato io ma anche quello che hanno forkato gli altri da quella data.
Giusto?

Ciao,

     Bruno.


| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

>From: Matteo Vaccari <vaccari@...>
>Date: Wed, 9 Oct 2002 14:08:16 +0200
>Allora forse potresti usare cvs checkout -D DATE; ti permette di
>recuperare la situazione del progetto a un istante arbitrario; cosi'
>puoi tornare alla situazione all'istante in cui hai fatto il tuo
>"branch" solitario.
>
>Matteo

Pero' avrei dovuto prima fare un check-in e quindi anche gli altri avrebbero
visto la mia versione e avrebbero potuto fare anche loro un check-out
durante un'integrazione (a meno di non usare un repository per ogni
workstation, vedi mail di Bruno). Giusto?

Andrea

_________________________________________________________________
MSN Hotmail è il provider email più grande al mondo… cosa aspetti a farti un
account? http://www.hotmail.it

Ciao Andrea,

se ho capito bene ti serve un modo per "congelare" il lavoro, tentare una nuova
strada ed evenutalmente riprendere dal frigo la versione congelata, senza pero'
usare CVS come frigo... giusto? :)

Beh, potresti esportare dei JAR che rappresentano le varie versioni
intermedie...
(Progetto_MiaVersione1.1.jar)

Oppure potresti usare il branching, che e' in CVS ma non fa parte del "HEAD"
quindi non genera gran confusione (anche se non ho mai provato, a dire il vero).

Oppure potresti modificare il plugin CVS ed aggiungere qualche funzionalita',
tipo "Create Local Version".

Oppure potresti usare le PATCH e salvarle sul file system locale.

Paolo.




>  from:    Andrea Vaccaro <andva@...>

Questo e' quello che facciamo nel caso di una integrazione: prima
verifichiamo che passino tutti i test e poi rilasciamo una nuova versione.
Il problema si pone quando tu vuoi fare una versione per te che non vuoi
condividere con il team perche' e' solo un tentativo temporaneo, magari
perche' stai per fare una mossa di refactoring e vuoi la liberta' di poter
pasticciare quanto vuoi.
In questo caso non vorrei usare il repository visto da tutti perche'
aggiungerei solo confusione agli altri pair