Newsgroup: it.comp.java
Titolo: MKS e JBuilder 6

Ciao.
Domandona: qualcuno di voi è riuscito ad integrare MKS Source Integrity (un
sistema di versioning sfigato) con JBuilder 6 ? Ho provato a guardarmi l'
interfaccia a linea di comando di questo coso e dopo vari tentativi non sono
arrivato a nulla. Qualcuno di voi ha gli stessi problemi ? Qualcuno di voi
ha famigliarità con la linea di comando di questo "coso" (MKS) ? Stavo
pensando ad un opentool per JBuilder se qualcuno sa darmi qualche
indicazione, non penso sia complicato da realizzare (prendendo come esempio
quelli già presenti).
Ciao
Luigi.

 quelli gią presenti).
C'e' gia' CVS che e' gratuito e presente su JBuilder6... Ha un 
difettuccio (che, se qualcuno e' riuscito a risolvere, mi farebbe un 
grosso piacere se dicesse come ha fatto :-) : non locka i file. Per usare 
la terminologia MKS, quando faccio il checkout di un file, questo non 
viene lockato, ed un altro utente puo' prenderlo e modificarlo. Poi, al 
momento di checkin, viene fatto il merge. Se questo non riesce, devi 
togliere i conflitti a mano. CVS di per se permette di richiedere 
l'editing esclusivo, ma con JBuilder non sono riuscita a capire come si 
fa e se si puo' fare.
Tutto questo lo saprai gia' di sicuro, diciamo che scrivo per salutarti 
piu' che altro :-))
Ciao,
Tatiana

 piu' che altro :-))
Grazie :-), un saluto anche a te, spero che ti trovi bene.
Avevo tolto il monitoring su questo thread, visto che non mi aspettavo che
nessuno più mi rispondesse. Mi sbagliavo :-)
ciao.
Luigi.

Ops ho fatto confusione, ho scambiato i nomi MKS e CVS un paio di volte nel
messaggio precedente.
correggo:
Credo che quel difettuccio di CVS sia una filosofia diversa di fuzionamento.
Quelli che lo usano dicono di trovarsi bene, evidentemente comunicano
egregiamente tra loro e si organizzano il lavoro per conto proprio.
Secondo me MKS si può integrare con JBuilder perché ha un'interfaccia a


l'editing esclusivo
Questo non lo sapevo. Neanche io ho trovato nulla in JBuilder che riuscisse
a sfruttarlo, infatti quando ho provato CVS per la prima volta sono rimasto
un po' perplesso per come funziona.

 nessuno più mi rispondesse. Mi sbagliavo :-)
Gia': chi altro usa (o ha usato) MKS ;-) ?!
Ciao,
Tatiana


Si, e' una filosofia diversa. In effetti noi qui (con VisualAge) usiamo lo stesso
approccio: tutti possono modificare tutto, quando vogliono, ed in fase di integrazione si
risolvono i conflitti. Ma non ce ne sono quasi mai. Certo, e' necessario integrare spesso
il proprio lavoro, anche 5 o 6 volte al giorno, ma non c'e' problema, anzi, e' un
vantaggio. Quando integri infatti vedi anche il codice scritto dagli altri, e questo ti
permette di mantenere una visione totale del sistema.
Ovviamente, "continuous integration", e' una pratica XP :-), ed e' particolarmente facile
da applicare se usata in sinergia con le altre.
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola

 da applicare se usata in sinergia con le altre.
Molto interessante.
Ciao,
Tatiana

 
Ad ogni integrazione (aggiornamento) noi ci assicuriamo che _tutto_ continui a funzionare
a dovere. Come? Grazie ad un'altra delle pratiche XP ("test first"), quella di scrivere i
test prima di scrivere il codice: da noi non esiste (almeno non dovrebbe :-D) un pezzo di
codice che non sia giustificato dalla presenza di un test che lo controlla. Abbiamo una
suite di test che copre l'intero progetto: prima e dopo l'integrazione ci assicuriamo che
la suite di test continui a dare "barre verdi", ovvero continui a funzionare.
Per farti un esempio, poco fa ho fatto girare la suite di test del nostro ultimo progetto,
un'applicazione java che genera alcuni documenti assicurativi prelevando dati da una GUI e
salvandoli su un DB centrale. Ecco il risultato (in formato testo) del lancio della test
con JUnit:
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
.........................................
........................
Time: 62,741
OK (885 tests)
Per darti un'idea del numero di test per caso d'uso, tieni conto che in fase di studio di
fattibilita' abbiamo individuato 15 casi d'uso.
E grazie per la domanda! Se non sono stato chiaro, son qui!
Ciao,
    Bruno.
P.S.
Porca putt... italia-corea 1-1, tempi supplementari, ora scappo a vedere :-/


 E grazie per la domanda! Se non sono stato chiaro, son qui!
Grazie a te :-) Sei chiarissimo, semplicemente non ho mai visto un 
progetto che non abbia bisogno dei grossi rifacimenti "in corso d'opera". 
Ciao,
Tatiana


Neanche io :-D!  Pero' il trucco e' mantenere basso il costo di questi cambiamenti, in
modo che tu possa approcciarli incrementalmente invece che di un botto. 
Se posso comunque identificare l'area per noi piu' critica, dove potenzialmente si possono
verificare questi intoppi, e' la GUI. Testare la GUI non e' facile, e la GUI per sua
stessa natura e' accoppiata: un cambiamento in quell'area ci puo' potenzialmente causare
problemi. Anche se noi lavoriamo totalmente con modelli (e quindi i cambiamenti "estetici"
sulle viste non ci toccano) c'e' il problema che i modelli stessi, a causa dei controlli
incrociati che a volte richiedono, sono accoppiati. Questo e' un problema sul quale stiamo
ancora riflettendo.
Ciao,
    Bruno.
P.S
Dall'altra volta che ti ho scritto sono state effettuate 5 integrazioni (6 con quella che
sto facendo ora) ed i test sono diventati 891 :-D. Nella mia integrazione ho pure avuto
delle barre rosse, in questo caso i test hanno gestito l'anti-regressione del codice. Se
ti interessa posso dettagliare cosa e' successo.
P.P.S.
Agli altri eventuali altri ascoltatori su questo thread: se l'argomento vi interessa, e
siete di Torino, alla prossima riunione del JUG locale e' possibile che si parli proprio
di TDD (Test Driven Development), che e' di fatto la pratica di "test-first design" che
cito. In alternativa potete intervenire al 
webb.it
, dove terro' un analogo seminario
domenica 7 luglio.


 un esempio?
Ad esempio (la prima cosa che mi viene in mente), ti cambia la struttura 
di una classe basilare del dominio applicativo (non so, viene modificato 
il significato di alcuni attributi). Questa classe, ovviamente, viene 
utilizzata un po' dappertutto. Inizi a modificare, e finche' non finisci, 
c'e' il rischio che una parte dell'applicativo non sia nemmeno 
compilabile. Per rimettere le cose a posto ci vuole un po' di tempo, e 
poi ci vuole un test totale, perche' la modifica non e' circoscritta.
Oppure (cosa successa qui da noi), nel colloquio con l'utente per caso 
vieni a sapere che una struttura ad albero su cui si basa l'applicativo, 
in realta' non e' sempre ad albero: c'e' una piccola eccezione, un 
elemento particolare che puo' avere due padri. Per l'utente e' un 
particolare di poco conto di cui non ha mai nemmeno accennato, ma che ora 
pretende che sia implementato subito, perche' importante e perche' 
secondo lui il costo di questa "eccezione" e' irrilevante.
[cut sul resto]
Grazie! Tutto molto interessante. Non vedo l'ora di sentire il tuo 
seminario al meet.
Ciao, 
Tatiana


Ok! Se verra' votato a sufficienza, pero! :-)
Ciao,
    Bruno.


 Ok! Se verra' votato a sufficienza, pero! :-)
Io l'ho votato ;-)
Grazie!
Tatiana
 

 
Si, confermo, ci vuole tempo e disciplina. Non e' facile da applicare, ma sul lungo rende:
certo, e' meglio dotarsi di una persona che ci abbia gia' provato prima di provarci da
soli :-)


La cose che stai dicendo sono molto interessanti, ci sono però alcuni
punti oscuri:
Se devi ad esempio, eseguire dei test su metodi che non ritornano nulla,
ma che eseguono una scrittura su db, il metodo che esegue il test come
fa
a sapere che sono stati riempiti tutti i campi con il formato corretto??
O altre cose simili??
Ciao,
Mauro Sensoli
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


E' semplice, in questo caso si lavora utilizzando la tecnica dei "mock objects", ovvero si
compone l'oggetto da testare con una versione "finta" degli oggetti che coinvolge.
Nel caso che descrivi tu io creerei un database finto, che rispetta l'interfaccia del
database vero ma che sotto non implementa nulla tranne che dei metodi di controllo per
verificare le azioni che vi sono state effettuate.
Ciao,
    Bruno.
