Rilasciato Intent v0.5

Community IT
1

Whoa, finito. Ce l’ho fatta
Intent-0.5http://rubyforge.org/projects/intent/è stato rilasciato su
rubyforge.

Non si ricorderà nessuno ma mi ero impegnato a farlo entro fine aprile e
-anche se technicamente è la mattina del primo maggio- ho finito!

Si tratta di un piccolo framework per fare una forma di test driven
development che io chiamo intent first.
Ho scritto un 2 minutes tutorial, un 5 minutes tutorial e un draft (temo
incompleto) del manuale.

Spero di ottenere suggerimenti dalla mailing list, apportare eventuali
correzioni e poi annunciarlo su ruby-talk.
In particolare vorrei impacchettarlo secondo buoni canoni di
accettabilità.
Non ho ancora esperienza in questo senso e forse mi potete dare una
mano.

Ciao,

–
Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/
Code Sushi: http://codesushi.blogspot.com/

2

— chiaro scuro [email protected] ha scritto:

Whoa, finito. Ce l’ho fatta
Intent-0.5http://rubyforge.org/projects/intent/è
stato rilasciato su
rubyforge.

congratulazioni :slight_smile:
Beh, mi tocca uscire di casa in 4 minuti quindi non
approfndisco ora, ma posso dirti già adesso di
attivare intent.rubyforge.org e metterci i doc, che è
decisamente utile, imho.

–
icq: #69488917
blog: http://riffraff.blogsome.com

Chiacchiera con i tuoi amici in tempo reale!
Yahoo Search - Ricerca nel Web | Motore di Ricerca

3

Whoa, finito. Ce l’ho fatta
Intent-0.5http://rubyforge.org/projects/intent/è stato rilasciato su
rubyforge.

Non si ricorderà nessuno ma mi ero impegnato a farlo entro fine aprile e
-anche se technicamente è la mattina del primo maggio- ho finito!

Viva il sincronismo, poche fa mi dicevo proprio la stessa cosa su Buzz
– con l’unica piccola, ehm, differenza che io mi ero impegnato a farlo
entro fine marzo…

Si tratta di un piccolo framework per fare una forma di test driven
development che io chiamo intent first.

Molto molto bene, davvero contento di vedere movimento in questo campo.
Specifiche eseguibili, che magari documentino anche, sono un toccasana
per il programmatore pigro. In passato ho rotto un po’ le scatole in
questo senso, probabilmente con l’unico risultato che Nathaniel
Talbott si ricorderà di me come “That guy that insists on making
examples executable”. :slight_smile: (Verso la fine di questo:
http://blog.hyperstruct.net/articles/2006/02/28/reptiles-in-classes-spiders-in-packages
parlo della mia versione per Javascript, che è ben lontana dal grado
di sofisticazione della tua, ma tu non avresti niente in contrario se
qualcuno pensasse di “ispirarsi” a Intent, veeero?).

Domanda: generi XML giusto per ricaricarlo facilmente o hai in mente
qualche postelaborazione tipo Intent->DocBook?

Ho scritto un 2 minutes tutorial, un 5 minutes tutorial e un draft (temo
incompleto) del manuale.

…e quando dopo esser passato dal primo al secondo ho letto la
spiegazione sulla “Progressive Laziness”, ho capito perché. Magari
però vuoi dargli nomi che li ordinino correttamente: sia nella shell
che nella GUI mi compare prima il 5 minuti, poi il completo, poi il 2
minuti.

Spero di ottenere suggerimenti dalla mailing list, apportare eventuali
correzioni e poi annunciarlo su ruby-talk.
In particolare vorrei impacchettarlo secondo buoni canoni di accettabilità.

Non ho ancora esperienza in questo senso e forse mi potete dare una mano.

Nei prossimi “coding esplorativi” che non hanno a che fare con Rails
(che usa test/unit) uso Intent e ti fo sapere.

Per qualcosa sulla pacchettizazione puoi guardare qua:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices. Non so
essere più specifico sulle rubygems perché non le uso se non
assolutamente costretto (il che sta diventando la norma più che
l’eccezione), ti chiedo solo la cortesia, se decidi di pacchettizzare
una .gem, di non seguire il deplorevole andazzo generale e mantenere
disponibile anche uno .zip o un .tar.gz.

–
Ever wondered who’s on the other side of the screen?
http://buzz.sameplace.cc

Do flatlanders dream of n-dimensional shapes?
http://blog.hyperstruct.net

4

Il giorno lun, 01/05/2006 alle 04.36 +0200, chiaro scuro ha scritto:

incompleto) del manuale.

Spero di ottenere suggerimenti dalla mailing list, apportare eventuali
correzioni e poi annunciarlo su ruby-talk.
In particolare vorrei impacchettarlo secondo buoni canoni di accettabilità .

Non ho ancora esperienza in questo senso e forse mi potete dare una mano.

Ciao,

più che per il semplice TDD, il tuo framework potrebbe essere molto
utile per creare acceptance tests a la XP.

Giovanni
5

Hai ragione, non trovare i docs è una cosa che rompe anche a me. Sarà
fatto.

On 5/1/06, gabriele renzi [email protected] wrote:

approfndisco ora, ma posso dirti già adesso di
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

–
Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

6

On 5/1/06, Massimiliano M. [email protected] wrote:

Si tratta di un piccolo framework per fare una forma di test driven
development che io chiamo intent first.

di sofisticazione della tua, ma tu non avresti niente in contrario se
qualcuno pensasse di “ispirarsi” a Intent, veeero?).

nessun problema, io mi sono ispirato da una parte a BDD (teoria di Dave
Astels), dall’altra ai robots di regression testing web.

Domanda: generi XML giusto per ricaricarlo facilmente o hai in mente

qualche postelaborazione tipo Intent->DocBook?

non avevo pensato a una postelaborazione, ma adesso che mi ci fai
pensare mi
sembra un’ottima idea. qualcuno di voi si intentde di RDoc? non sarebbe
male integrarli in qualche modo…

Ho scritto un 2 minutes tutorial, un 5 minutes tutorial e un draft (temo

incompleto) del manuale.

…e quando dopo esser passato dal primo al secondo ho letto la
spiegazione sulla “Progressive Laziness”, ho capito perché. Magari
però vuoi dargli nomi che li ordinino correttamente: sia nella shell
che nella GUI mi compare prima il 5 minuti, poi il completo, poi il 2
minuti.

si, è vero, me ne sono accorto anch’io… :frowning:
li
rinominerò.
Nei prossimi “coding esplorativi” che non hanno a che fare con Rails

(che usa test/unit) uso Intent e ti fo sapere.

ahi, speriamo vada bene :slight_smile:
io lo uso in genere da scite, mai provato sotto altri editor.

Per qualcosa sulla pacchettizazione puoi guardare qua:

http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices. Non so
essere più specifico sulle rubygems perché non le uso se non
assolutamente costretto (il che sta diventando la norma più che
l’eccezione), ti chiedo solo la cortesia, se decidi di pacchettizzare
una .gem, di non seguire il deplorevole andazzo generale e mantenere
disponibile anche uno .zip o un .tar.gz.

credo però che anche una gem sia apribile come zip o sbaglio?

–
Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

7

Si, in realtà TDD è solo uno degli aspetti.

L’altro aspetto, quello che menzione nel 5 minutes tutorial è i
‘progressive
levels of testing laziness’.

Ovvero puoi partire testizzando esempi di codice che contengono semplici
puts e step by step arrivare fino agli intents.

Per ora inoltre non supporto esplicitamente il mocking, che ritengo però di
grande aiuto per uno sviluppo in team.

On 5/1/06, Giovanni C. [email protected] wrote:

[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

–
Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

8

Nei prossimi “coding esplorativi” che non hanno a che fare con Rails

(che usa test/unit) uso Intent e ti fo sapere.

ahi, speriamo vada bene :slight_smile:
io lo uso in genere da scite, mai provato sotto altri editor.

Non so cosa combini da scite :-), ma da Emacs mi limito ad avviare lo
script (o a inviarlo ad una sessione di irb), dovrebbe bastare.

credo però che anche una gem sia apribile come zip o sbaglio?

Come tar, per la precisione, e quello non è un problema. Il problema
arriva dopo, quando devi gironzolare per i sorgenti a caccia di tutti
i “require_gem”.

Massimiliano

9

On 5/4/06, Massimiliano M. [email protected] wrote:

ahi, speriamo vada bene :slight_smile:
io lo uso in genere da scite, mai provato sotto altri editor.

Non so cosa combini da scite :-), ma da Emacs mi limito ad avviare lo
script (o a inviarlo ad una sessione di irb), dovrebbe bastare.

niente, solo una questione di formattazione del testo.
il testo formattato in un certo modo ha un significato particolare per
SciTe
(esempio: ti manda sulla riga di testo dove c’è un errore.)

10

— chiaro scuro [email protected] ha scritto:

Whoa, finito. Ce l’ho fatta
Intent-0.5http://rubyforge.org/projects/intent/è
stato rilasciato su
rubyforge.

finalmente un filo di tempo per rispondere in modo
esteso. In generale non sono riuscito ancora ad
entrare nella logica di intent.

Il concetto è che io debba poter esprimere una serie
di fatti sul programma in una forma quanto più
possibile discorsiva, fin qui ci sono.

Però, giacché i test li leggerà comunque un’altro
sviluppatore, quali sono i vantaggi di usare uno stile
più discorsivo?

Voglio dire, perché:
assert [‘tdd’,‘bdd’,‘idd’].member?(‘idd’)
è meno chiaro di
‘idd’.should_be_one_of [‘tdd’,‘bdd’,‘idd’]
?

Usare intent, per me pigro, ha senso se ho una serie
di “espressioni” estremamente concise, ad esempio
intent_of(?making a winning move?) → to “win”
expect :X, as=game.winner → x.is game.winner

Ma in assenza di ciò penso che preferirei ancora il
caro vecchio Test::Unit. A proposito, non ho ravanato
abbastanza nel codice, ma non mi pare che tu abbia
usato T::U come base, come mai? Non abbastanza
flessibile?

Infine: io generalmente uso irb per fare le prove
invece di puts, pero non ho idee su come integrarlo :slight_smile:

–
icq: #69488917
blog: http://riffraff.blogsome.com

Chiacchiera con i tuoi amici in tempo reale!
Yahoo Search - Ricerca nel Web | Motore di Ricerca

11

Voglio dire, perché:
assert [‘tdd’,‘bdd’,‘idd’].member?(‘idd’)
è meno chiaro di
‘idd’.should_be_one_of [‘tdd’,‘bdd’,‘idd’]
?

Personalmente essendo poco abituato alla gestione dei test, e non avendo
esperienza alle spalle la versione di intent è sicuramente più leggibile e
semplice da utilizzare. Naturalmente come la maggior parte delle volte
è una
semplice questione di gusti, ma anche i programmatori amano le cose
naturali
e semplici :slight_smile:

Ritornando all’idea del web semantico (visto in discussioni precedenti),
quanto fatto da chiaro scuro è simile per il concetto che cercano di
raggiungere. Si cerca di descrivere ciò che si vuole fare nel modo più
vicino al nostro linguaggio naturale, cercando di raggiungere la
maggiore
potenza espressiva possibile.

–Andrea R.

12

Però, giacché i test li leggerà comunque un’altro
sviluppatore, quali sono i vantaggi di usare uno stile
più discorsivo?

Voglio dire, perché:
assert [‘tdd’,‘bdd’,‘idd’].member?(‘idd’)
è meno chiaro di
‘idd’.should_be_one_of [‘tdd’,‘bdd’,‘idd’]
?

Penso sia una questione di ottica, non chiarezza (entrambi gli esempi
sono chiari nelle rispettive ottiche).

Se adotti l’ottica che non stai testando una unità, ma scrivendo una
specifica che una futura unità dovrà rispettare, più che esprimere
un’asserzione risultato di un evento appena accaduto trovi naturale
esprimere una regola su come i futuri eventi dovranno apparire. Il
fatto che la specifica sia poi verificabile dalla macchina diventa
collaterale.

Personalmente mi ci trovo abbastanza, si dice che il test-first design
sia questione primariamente di design, non di testing, e linguaggi
tipo Intent mi sembra che riallineino il linguaggio allo scopo
primario della pratica. (O magari è solo che funzionano molto bene da
documentazione, e soddisfano quindi la mia pigrizia. :-))

Massimiliano

13

Spero solo che Gabriele non ravani troppo nel codice… non ne sono molto
orgoglioso purtroppo… anzi, se hai dei consigli sono ben accetti.

Intanto, grazie a tutti per i commenti che mi danno l’opportunità di
raccontarvi quello che faccio. Tra Andrea e Massimiliano sono stati
coperti
abbastanza bene i punti che mi hanno portato a intent. Li riprendo
cercando
qui le mie motivazioni iniziali e sollevando altri spunti di
riflessione.

Intent ha quattro aspetti:

Il primo aspetto è quello che Massimiliano definisce di specifica. Se
penso
in termini di quello che voglio piuttosto che di quello che devo
testare,
focalizzo meglio il mio intento (da qui il nome). Forse è una differenza
solo di parole, ma le parole sono pensieri, modi di vedere le cose e poi
azioni. Insomma è un punto forse più filosofico che pratico. non ci sono
forti argomentazioni purtroppo e anche l’anedottica è scarsa. in questo
però a me piace così :slight_smile:

Il secondo aspetto che sottolinea Andrea è quello della leggibilità. I vari
intenti vengono messi in prosa (prozed) per poter essere letti. E mi
piacerebbe che potessero essere letti anche da utenti esperti. Ci tengo
al
fatto che il codice o perlomeno delle sue parti divengano ubique e non
chiuse nella piramide di un repository. Anzi gli intenti li vorrei
addirittura su un wiki, dove i miei utenti li possono vedere (prozed) e
editare (come codice). Quest’ottica mi obbliga a scrivere degli intent
leggibili e quindi anche le mie API devono essere leggibili, almeno nel
loro
strato più superficiale. Quindi lo strato superiore del codice viene
plasmato seguendo le linee del linguaggio di dominio dell’utente.

Il terzo aspetto, che voi sottovalutate perchè siete tutti bravi e onesti
sviluppatori, è quello della pigrizia estrema. Provate a convincere
qualcuno a fare dei test. è come spiegargli che è divertente andare dal
dentista. In questo senso puoi prendere del codice con dei brutali puts
e
con un minimo sforzo da detestabile renderlo almeno testabile. sempre
con
piccoli sforzi man mano che lo sviluppatore pigro si convince potrà
spostarsi su e più su lungo la scala evolutiva.

Il quarto aspetto è l’intuizione. come andare dall’intuizione all’intento?
Quando scrivo codice spesso esploro e non mi è possibile definire
formalmente un intento in anticipo… perchè non so quello che voglio.
Quello che voglio a volte è quello che posso fare e questo lo scopro solo
facendolo. Finita l’esplorazione mi trovo però con un piccolo groviglio di
codice intestabile. Usando Intent posso fare ‘intent refactoring’,
estraendo l’intento del codice step by step: prima come ‘memoria’ (solo
l’output), poi come ‘fatti’ (relazioni di causa-effetto), poi come
‘storia’
(una serie di eventi) e infine come ‘intenti’ (unità atomiche di
intenzionalità)
Per rispondere invece a Gabriele sul perchè non mi sono basato su test
unit: è stata per lo più pigrizia e voglia di giocare con ruby che stavo
giusto imparando. non usavo ancora il framework ma ero abbastanza
sicuro
che fosse in stile junit. Io invece volevo portarmi fuori dallo stile
junit
che mi sembrava troppo restrittivo davanti alla possibilità di usare DSL
in
ruby. Inoltre non mi piaceva quella struttura rigida di classi. Volevo
specificare il mio codice in modo più leggero e free-form.

14

On 5/7/06, gabriele renzi [email protected] wrote:

si, concordo in pieno suquesto, quello che dicevo è
che potresti generare testcase e metodi in stile xUnit
all’interno di intent mantenendo esposta la stessa interfaccia

mi sono fatto prendere dalla risposta e ho dimenticato la domanda :slight_smile:

avevo pensato di fare come dicevi tu, poi ho pensato che comnuque nella
maggior parte dei casi sarebbe stato solo questione di confrontare due
variabili e stampare passed/failed. e quindi l’ho fatto per conto mio.

credi che usando test/unit riuscirei a riutilizzare altre feature che mi
possono tornare utili?

15

— chiaro scuro [email protected] ha scritto:

Io invece volevo portarmi
fuori dallo stile junit
che mi sembrava troppo restrittivo davanti alla
possibilità di usare DSL in
ruby. Inoltre non mi piaceva quella struttura
rigida di classi. Volevo
specificare il mio codice in modo più leggero e
free-form.

si, concordo in pieno suquesto, quello che dicevo è
che potresti generare testcase e metodi in stile xUnit
all’interno di intent mantenendo esposta la stessa interfaccia

–
icq: #69488917
blog: http://riffraff.blogsome.com

Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it