Ciao a tutti,

con enorme umiltà volevo segnalarvi un piccolo diario di bordo
che traccia l'esperienza degli ultimi sette mesi circa sulla graduale
adozione di XP nel team di cui faccio parte.

I post sono raggiungibili sul mio blog (ebbene sì un altro blog!) sotto
la categoria Diario Di Bordo:

http://www.request.to.it/enri/index.php?d=27&m=04&y=06&category=4

Ovviamente critiche e/o commenti non sono graditi... di più! ;-)

--
Enrico Mangano
http://www.request.to.it/enri

Ciao a tutti,

Vi inoltro questo annuncio nel caso che qualcuno sia interessato alla
cosa.

Stiamo organizzando uno Smalltalk Party a Cagliari per il giorno sabato
1 luglio. Sarà una grande occasione per qualche chiacchierata
amichevole, per incontrare altri Smalltalker e per conoscere una
spendida parte d'Italia.

Il party si terrà nei locali dell'Università di Cagliari
( http://www.unica.it ) ed è sponsorizzato dall'Agile Group
( http://agile.diee.unica.it ).

Se siete interessati a venire al party, aggiungete il vostro nome allo
swiki
http://smalltalkit.seasidehosting.st/seaside/pier/SmalltalkParty20060701, oppure
mandate una email a giovanni@... .

Il wiki contiene anche delle informazioni turistiche che possono esservi
utili.

	 Giovanni

Ciao a tutti,

Mi presento: lavoro come sviluppatrice essenzialmente Java (anche se
ultimamente col mio gruppo stiamo utilizzando Ruby per la parte di
Acceptance Testing) e per mia grande fortuna, ho iniziato quasi subito
a lavorare in contesti xp.

La mia esperienza lavorativa non è sicuramente decennale ;), ma la
reputo di qualita' e con risvolti estremamente formativi e di crescita
proprio in virtu' del valore aggiunto che XP riesce a portare, con i
suoi principi e le sue pratiche, alla professionalita' di noi
sviluppatori.

Non aggiungo altro, ma solo buon lavoro a tutti e grazie per tutti gli
spunti di riflessione nati da questa mailing list!

Ciao,

Claudia

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.5/333 - Release Date: 05/05/2006

In bocca al lupo Roberto e benvenuto.

Francesco

Scrive Roberto Gianassi <robertogianassi@...>:

>
> Ciao a tutti,
>
> innanzitutto complimenti per la mailing list! ;-)
>
> Mi chiamo Roberto e lavoro nel settore della programmazione da 9 anni.
> Ho lavorato in vari ambiti (web, enterprise, scientifico e adesso
> quasi-automazione) , con vari linguaggi (C++ poi ASP, Java e adesso VB6)
> e con vari strumenti (da Visual Studio e precedenti a JBuilder e Eclipse).
>
> Le metodologie agili di sviluppo software (tra cui XP) mi hanno sempre
> interessato molto anche se purtroppo non ho mai avuto la fortuna di
> lavorare in team XP.
>
> Dato che sto valutando la possibilita' di cambiare aria lavorativa vi
> vorrei chiedere se siete a conoscenza di aziende "agili" nella zona tra
> Firenze, Prato e Pistoia.
>
> Non so che contributo potro' dare a XP (a parte "spiare" questa ML).
>
> Per ora buon lavoro e ciao alla prossima,
>
> Roberto
>
>


...........................
   Dott. Francesco Cirillo
   CEO, XPLabs SRL
   Coach, Bees Team
   Tel +39 06 452.14.734
   Tel +39 02 303.56.742
   Mob +39 338 76.35.115
   Fax +39 06 233.236.936
   Via dei Castagni, 22
   01015 Sutri (VT)
   http://www.xplabs.it
...........................

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

We are pleased to announce the following seminar.

No registration is needed.

For further information on the seminar series and on how to reach the
Faculty, please visit the web page

http://www.unibz.it/inf/csseminars/seminars2006/index.html?LanguageID=EN

09.05.06 - 09.05.06, 14:30-15:30 - Faculty of Computer Science, Free
University of Bolzano-Bozen, P.za Sernesi, 1, room D101

*The Eclipse Way*
/Erich Gamma/

	
</printerversions/newsfull.html?LanguageID=EN&contentid=3817&pageid=15&PV=TRUE&S\
HOW_CMD=FALSE>





   	 Abstract. Eclipse received awards for Best Value, Best Open Source
Tool and Most Improved Tool.

CV. Erich Gamma currently is an IBM Distinguished Engineer at IBM's
Object Technology International (OTI) lab in Zurich, Switzerland. He
provides leadership in the Eclipse community, and is responsible for the
Java development effort for the Eclipse platform. Erich Gamma lept onto
the software world stage in 1995 as co-author of the best-selling book
Design Patterns: Elements of Reusable Object-Oriented Software
(Addison-Wesley, 1995). This landmark work, often referred to as the
Gang of Four (GoF) book, cataloged 23 specific solutions to common
design problems. In 1998, he teamed up with Kent Beck to produce JUnit,
the de facto unit testing tool in the Java community.

Reference person: Barbara Russo <mailto: Barbara.Russo@...>

Ho una lista infinita di "massime" che mia nonna mi ripete fin da
quando sono bambino, alcun di queste non le ho ancora capite (es. il
brodo fa venire le gambe grosse) altre le riconosco nella vita di
tutti i giorni. Una delle cose che mia nonna mi dice da sempre e':
"Fai una cosa alla volta".
Nel mio team siamo, by design, sottoposti a veloci context switch
perche' il numero dei progetti su cui lavoriamo (per lo piu'
manutenzione evolutiva) e' molto piu' alto del numero di sviluppatori,
ogni progetto ha poi piu' di un cliente con esigenze particolari.
Sulla carta il problema non esiste, cambi progetto ma cmq quando cambi
"dimentichi" il precedente e per quell'iterazione lavori ad una sola
cosa, nella pratica invece ...

Siccome un'altra massima di mia nonna e' che "vale piu' un'ora di
pratica che un mese di grammatica" vorrei avere il vostro feedback
sulla cosa. Anche a voi sperimentate difficolta' a "fare una cosa alla
volta" ? Vi pesa ?

Ciao
Nicola

realknip wrote:
> Siccome un'altra massima di mia nonna e' che "vale piu' un'ora di
> pratica che un mese di grammatica" vorrei avere il vostro feedback
> sulla cosa. Anche a voi sperimentate difficolta' a "fare una cosa alla
> volta" ? Vi pesa ?
>
Sì e sì. La cosa non è lineare. Se cambio contesto più volte a
settimana, allora due progetti insieme vanno ancora bene. Arrivato a
tre, si sentono sinistri scricchiolii. Più di quello, ho difficoltà a
fare progressi su ogni singolo progetto.

Le cose migliorano molto quando riesco a mettere insieme
un'infrastruttura per ridurre l'overhead del cambio di contesto. Se devo
andare a rileggere della documentazione o del codice lasciato a metà,
sono guai. Se tutto quello che devo fare per cambiare task è leggere una
lista di modifiche su un Wiki, fare un checkout e far girare i test,
allora riesco a parallelizzare meglio.

Quando il codice è tutto mio, o quando lavoro su un progetto dove non si
integra spesso, una tecnica che per me funziona benissimo è "leave the
last test broken". E' incredibile quanto faccia questo piccolo trucco
per riportarmi immediatamente con la testa nel punto dove avevo
interrotto il lavoro. Ancora non sono del tutto a mio agio con l'idea di
andare a dormire con una barra rossa, ma dopo un po' ci si abitua.

So che ci sono persone che non riescono a seguire più di un progetto
alla volta, e altre che sono perfettamente a proprio agio con tre o
quattro. E' in parte un fatto di abitudine, ma è anche una questione di
carattere, e in questo caso le forzature fanno male. "Chi nasce tondo
non muore quadro", dice mia nonna.

Carlo Bottiglieri wrote:
> On 5/12/06, *Paolo Nusco Perrotta* <ml@...
> <mailto:ml@...>> wrote:
>
>
>     Quando il codice è tutto mio, o quando lavoro su un progetto dove
>     non si
>     integra spesso, una tecnica che per me funziona benissimo è "leave
>     the
>     last test broken".
>
>
> E' esattamente quello che faccio io per i progetti in solitaria! Che
> bello sapere che non sono l'unico eretico.


In realtà siamo anche troppo ortodossi... Ho preso la tecnica pari pari
dal libro Test-Driven Development di Kent Beck
(http://www.klaustrofobik.org/blog/archives/000208.html).

Quel libro decisamente mi manca, devo provvedere.

Sicuro?

Lerning by doing...

...e infatti c'eri già...

 

= )

 

(...cmq bellissimi i vekki proverbi ke nn muoiono mai... -riferito a fai una cosa alla volta-)

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

Non sono sicuro di avere capito bene; ma questa frase

>  Quello che vorremmo testare, in questo caso, è come il flusso del metodo
> stesso: i.e., quali messaggi manda a quali oggetti.

mi fa sospettare che in qualche modo dai per scontato e fissato il
design esistente.  Sarà che io tendo a ragionare più in termini di
stato che di interazioni, ma puoi spiegarci meglio perché è importante
testare la sequenza di chiamate?

Voglio dire, questi oggetti con cui devi parlare sono oggetti esterni
alla tua applicazione, e quindi il tuo requisito è che venga fatta
un'interazione con l'esterno con certe chiamate in un certo ordine,
oppure questi oggetti sono interni alla tua applicazione, e allora
potresti concentrarti di più sullo stato in cui vuoi farli arrivare?

Matteo

On 5/17/06, Paolo Bizzarri <pibizza@...> wrote:
>
>  Salve a tutti,
>
>  in ditta stiamo ragionando, in modo abbastanza intenso, su come strutturare
> il codice per migliorare la testabilità.
>
>
> Ho mandato una domanda sulla mailing list di TDD, ma vorrei sottoporre la
> stessa domanda anche alle persone qui su xp-it.
>
>  Diciamo di avere una classe Core, e di voler testare un metodo chiamato
> doSomethingOnFolder.
>
>  def doSomethingOnFolder(self, folder_id):
>      folder = self.getFolderFinder().findById(folder_id)
>      if (folder.isAccessible()):
>         document = self.getDocumentFinder().findByFolderId(folder_id)
>         document.performSomething(folder.getTitle())
>
> (La semantica esatta non è importante)
>
>  Quello che vorremmo testare, in questo caso, è come il flusso del metodo
> stesso: i.e., quali messaggi manda a quali oggetti.
>
>  Per farlo, siamo costretti ad utilizzare molti mock "profondi", nel senso
> che sono mock che ritornano altri mock che ritornano altri mock...
>
>  Per provare a migliorare le cose, abbiamo provato a incapsulare le
> interazioni con oggetti esterni in metodi privati, e a utilizzare il pattern
> Composite Method.
>
>  def doSomethingOnFolder(self, folder_id):
>      folder = self._retrieveFolder(folder_id)
>      if (self._isAccessible(folder)):
>         document = self._retrieveDocument(folder_id)
>         self._performSomething(folder)
>
>
>  Ora, i metodi tipo _retrieveFolder possono essere testati autonomamente, e
> anche in modo piuttosto semplice. Il problema è che il metodo
> doSomethingOnFolder deve ancora essere testato con una caterva di Mock
> intorno.
>
>  Tuttavia, il codice sembra (e sottolineo sembra) suggerire che potremmo
> separare i metodi helper dal flusso principale, e creare un oggetto
> separato:
>
>  Class Core:
>
>  def __init__(self, helper)
>      self.helper = helper
>
>  def doSomethingOnFolder(self):
>      folder = helper._retrieveFolder(folder_id)
>      if (helper._isAccessible(folder)):
>         document = helper._retrieveDocument(folder_id)
>         helper._performSomething(folder)
>
>  class Helper:
>
>    def _retrieveFolder(folder_id):
>       return "something"
>
>  ecc...
>
>  In questa maniera, possiamo creare in fase di testing un MockHelper, che
> implementa la stessa interfaccia, ma ci rende le cose decisamente più
> semplici.
>
>  Idee e suggerimenti ?
>
>  Ciao
>
>  Paolo
>
>  ________________________________
>  Collegamenti utili di Yahoo! Gruppi
>
>
> Per andare all'homepage del gruppo:
> http://it.groups.yahoo.com/group/extremeprogramming-it/
>
> Per annullare l'iscrizione al gruppo, scrivi a:
> extremeprogramming-it-unsubscribe@yahoogroups.com
>
> L'utilizzo da parte tua di Yahoo! Gruppi è soggetto alle Condizioni Generali
> di Utilizzo del Servizio.


--
http://matteo.vaccari.name

Il giorno mer, 17/05/2006 alle 11.07 +0200, Paolo Bizzarri ha scritto:
>
> In questa maniera, possiamo creare in fase di testing un MockHelper,
> che implementa la stessa interfaccia, ma ci rende le cose decisamente
> più semplici.
>
> Idee e suggerimenti ?
>
Così d'istinto mi viene da pensare che la tua classe Core abbia troppe
responsabilità. Non puoi spostare la logica nella classe Folder?

	 Giovanni

>

Ciao Paolo,



Alcune osservazioni sparse:

* Noto che sono accoppiate le operazioni di creazione e recupero di
informazioni.
Parlo, ad esempio, del registration_id e del parent_id. Se si svincolassero le 2
operazioni sarebbe tutto più comodo.
La creazione potrebbe tornare oggetti, non id. Poi tali oggetti potrebbero
comunicare tra loro. Per rendere concreto il pensiero:

** durante la creazione di instance:
         instance = self.getInstance(instance_id)
    il quale, al suo interno:
	 instance._newRegistration(), il quale registra come field il registration_id

** nel metodo autoDoIncomingRegistration(self, instance,**args):

         self.getRegistrations().newRegisteringEventFor(instance) // il quale, al
suo interno, setta l'eventID.

	 command = AssignmentEventTracing(instance) // recupera i registration_id,
parent_id tramite getter di "instance"

         self.startAssignmentAndNotify(instance, command)

         if instance.getProperty('to_scan', 0): 
self.startScanProcess(instance.registration_id)
         return instance.registration_id

Un test potrebbe passare una istanza di "instance" creata ad hoc e verificare
che, al termine dell'invocazione del metodo, l'event Id è aggiornato.
Un altro test può verificare il funzionamento del metodo quando è settata la
property "to_scan" e così via..

* Il log può essere una operazione a parte. Quindi, prima di chiamare
autoDoIncomingRegistration (che nell'esempio ha un argomento non usato) si
potrebbe chiamare una procedura di log, da eseguire dopo la creazione di
"instance" o dopo l'esecuzione della procedura autoDoIncomingRegistration

instance = self.getInstance(instance_id)
LogInserimentoRegistrazioneIngresso(self, instance) : ...
autoDoIncomingRegistration(self, instance **args): ...


Spero di averti suggerito buone idee ;-)
Buon lavoro,

Tommaso Torti

>Io non vorrei tanto verificare se un certo valore della istance è stato
>settato, quanto piuttosto andare a vedere se alla istance è arrivato un
>certo messaggio.

Una soluzione potrebbe essere:

Si potrebbe creare un nuovo oggetto che estende quello under test ed esegue
override di tutti i metodi che vuoi testare.
Quindi, se vuoi testare che venga chiamato il metodo registerEventID(...)
sull'oggetto di tipo A, crei un oggetto di tipo B che estende A, ridefinisce
registerEventID in questo modo:

registerEventID (parametri ...) :
  e'statochiamatoilmetodoregistereventid = true
  super(parametri ...)

Il test accedera' a quell'informazione permettendoti di asserire che <<alla
istance è arrivato un certo messaggio>>.

Hai gia' provato qualcosa del genere? Se si' , quali difficolta' hai incontrato?

Ciao !

Tommaso Torti

<<L'impressione è che ci sia un altro oggetto "sotto", che sta premendo per
emergere>>

...che emergerà una volta che avrai i test che ti supportano in questa
operazione ;-)

Si può anche osare una reificazione senza test, purchè tu abbia confidenza!

Tommaso Torti

Ciao a tutti.

Come buona educazione mi presento.

Sono un giovane catanese che ha deciso di emergere, o se volete, emigrato per
lavoro. :)
Partecipo da un bel po' di anni alle attivita' del FreakNet MediaLab (per chi
non lo conoscesse www.freaknet.org) e un ambiente moooooolto creativo e
stimolante.
La mia formazione e' tutta su sistemi operativi e reti, ma programmo per
diletto e necessita' di sysadmin. Partito da Win sono stato folgorato sulla
via di Damasco ed ho iniziato a studiare ed appassionarmi ai sistemi unix
(tutti meno SCO! :) ) ed alle reti. Dopo una buona dose di cisco mi sono
ritrovato (e sto cercando ancora di capire come...) a fare configuration
management.
La vera storia e' che potrei fare di tutto in informatica, vista la passione,
purche' il "tutto" non sia scontato.
Di XP, conosco il nome, ho sentito qlcs e ho conosciuto il buon Francesco, che
ritrovo qui... anzi direi che e' lui che ritrova me qui ;). Francesco mi ha
fatto incuriosire per cui eccomi qua!

Staro' "tunato" per vedere che succede.

A presto,
Marco

Ciao a tutti.

Come buona educazione mi presento.

Sono un giovane catanese che ha deciso di emergere, o se volete, emigrato per
lavoro. :)
Partecipo da un bel po' di anni alle attivita' del FreakNet MediaLab (per chi
non lo conoscesse www.freaknet.org) e un ambiente moooooolto creativo e
stimolante.
La mia formazione e' tutta su sistemi operativi e reti, ma programmo per
diletto e necessita' di sysadmin. Partito da Win sono stato folgorato sulla
via di Damasco ed ho iniziato a studiare ed appassionarmi ai sistemi unix
(tutti meno SCO! :) ) ed alle reti. Dopo una buona dose di cisco mi sono
ritrovato (e sto cercando ancora di capire come...) a fare configuration
management.
La vera storia e' che potrei fare di tutto in informatica, vista la passione,
purche' il "tutto" non sia scontato.
Di XP, conosco il nome, ho sentito qlcs e ho conosciuto il buon Francesco, che
ritrovo qui... anzi direi che e' lui che ritrova me qui ;). Francesco mi ha
fatto incuriosire per cui eccomi qua!

Staro' "tunato" per vedere che succede.

A presto,
Marco

mercoledi 17 maggio 2006, alle 11:48, il navigatore Paolo Bizzarri scrisse:

Mi permetto anch'io qualche piccolo pensiero:

1:
> In realtà, il nostro obiettivo è esattamente quello di
> modificare il design esistente, ma (purtroppo...) molte parti del
> nostro codice non sono in questo momento adeguamente sottoposte a
> test.

2:
> Inoltre le parti del codice su cui ragiono spesso non hanno uno
> stato interno su cui ragionare, ma sono piuttosto oggetti che
> lavorano smistando informazioni da e verso altri oggetti.

3: Il codice che hai postato, tipo
def autoDoIncomingRegistration(self, instance_id, workitem_id, **args):
   instance = self.getInstance(instance_id)
   protocol_data = instance.getProtocolData()
   self.getLogger().putLogMessage(
  	 "Inserimento Registrazione Ingresso n. %d, ambito: %s, AOO: %s" % (
		 protocol_data.number(),
		 protocol_data.kind(),
		 protocol_data.areaCode()))
   registration_id =  instance._newRegistration()
   parent_id = self.getRegistrations()._newRegisteringEvent(registration_id)
   instance.setEventId(parent_id)
   command = AssignmentEventTracing(instance, registration_id, parent_id)
   self.startAssignmentAndNotify(instance, command)
   if instance.getProperty('to_scan', 0):
     self.startScanProcess(registration_id)
   return registration_id

4: L'utilita' dei mock all'interno dei test
5: L'idea di utilizzare degli Helper

Sono tutti indicatori sintomatici di codice procedurale, se mi
chiedessero di descrivere il codice di cui sopra, direi immediatamente
che si tratta di un "mediator", che di per se non avrebbe nulla di
sbagliato, ma quando iniziano ad essercene troppi di mediator...

Facciamo alcune considerazioni:
- a prima occhiata sembra un po' lungo
- interagisce con un po' troppi oggetti (come hai fatto notare)
- "invidia" un po' troppo i dati degli oggetti con cui interagisce
   (bad smell: features envy)
- "conosce" un po' troppo il funzionamento degli oggetti con cui
   interagisce => questo bad smell e' facilmente riconoscibili quando
   trovi degli accoppiamenti temporali fra le chiamate di metodi,
   ovvero si vengono a creare spontaneamente dei "pattern" di codice
   che si ripetono un po' ovunque

Come procederei io? Nella maniera piu' pragmatica possibile inizierei
a costruire degli "smoke test", ovvero dei test funzionali (non
unitari) che ti possono dare una ragionevole rete di sicurezza.
Prenderei i metodi di cui sopra e inizierei a fare piccoli passi di
refactoring del tipo:
- descrivi in speudo codice ad altissimo livello il metodo da
   rifattorizzare
- per ogni passo di pseudo codice identifica il blocco di codice
   relativo o commentalo nel modo piu' breve e comunicativo possibile
- estrai ogni blocco in un metodo a parte il cui nome rievochera' il
   commento che avevi dato precedentemente al blocco
Ora, guardando questi nuovi metodi, molto probabilmente quei metodi
starebbero molto meglio se appartenessero ad altre classi (features
envy), spostando i metodi nelle relative classi di appartenenza si
avrebbero a questo punto dei metodi che agiscono direttamente con i
dati delle istanze di quella classe, metodi perfettamente testabili
senza l'ausilio di mock. Per farti un'idea piu' concreta potresti
leggerti un saggio dei PP: "Keep It DRY, Shy, and Tell the Other Guy"
http://www.pragmaticprogrammer.com/articles/may_04_oo1.pdf

Perche' i mock nel tuo caso non sarebbero una soluzione? Tu stesso hai
detto che il vostro obiettivo e' quello di cambiare il design attuale,
i mock non farebbero altro che peggiorare la situazione rendendo molto
piu' lento il cambiamento. Pensaci bene, imbrigliando la comunicazione
innescata dal metodo di cui sopra, come pensi di poterlo modificare
successivamente se non modificando anche il test?

Perche' gli helper non sarebbero una soluzione? Perche' con gli helper
stai cercando di catturare i "pattern" di cui parlavo prima, "pattern"
che sono strettamente legati al funzionamento interno di alcuni
oggetti del tuo sistema, isolare questi "pattern" all'interno di
anonime classi helper contribuirebbe a rendere ancora piu' procedurale
il codice esistente, senza renderlo piu' testabile (la modalita' di
test piu' appetibile sarebbe ancora quella di utilizzare i mock)

I mock sono molto utili quando l'interazione fra un oggetto (l'oggetto
da testare) e gli altri conoscenti e' direttamente dipendente dallo
stato in cui si trova l'oggetto stesso. Un caso tipico e' quello di un
parser sax: a fronte di una sequenza di eventi esterni (elementi di un
documento xml), il parser invoca su determinati oggetti determinati
metodi, i quali possono a loro volta modificare lo stato del parser.
In sostanza quindi una complessita' combinatoria di eventi e stati che
devono poter essere testati. Nel metodo di cui sopra, secondo il mio
parere, utilizzando dei mock testeresti solamente la capacita'
dell'interprete python di interpretare le invocazioni di metodi
elencate e niente altro

Scusate la lungaggine, e gli errori che ci saranno... vista l'ora

--
Gabriele Lana
contact me at gabriele dot lana at agilemovement dot it
http://www.agilemovement.it - Italian Agile Movement
http://www.xpug.it - italian eXtreme Programming User Groups

Ciao a tutti :)
Ho un quesito per voi.
Abbiamo per le mani una specie di SSO, realizzata con due servlet
deployate su due web container diversi; nella fattispecie 2 Tomcat.
I/Le 2 servlet si scambiano comandi (action) del tipo
login/logout/cambiaPwd/pwdCambiata/cambiaRuolo/ruoloCambiato e dati di
sessione via Cookie e/o via JSESSIONID.
In questo momento il codice è 'legacy', nel senso che non siamo in
grado di testare in maniera automatica una determinata sequenza di
action e i loro risultati, perchè ci sono di mezzo svariati controlli
cookie/non cookie/url rewriting/url non rewriting che non ho le
conoscenze per poter 'mockare'... :(

La domanda da 100 milioni di pistole è: come si testa un truschino del genere?

Grazie
Ciao
--
Giorgio Vespucci
giorgio.vespucci@...