tonyx

Global Day of Coderetreat in Milan

2011-12-08T14:52:00.007+01:00

3th of December was a wonderful day, with around 25 enthusiast people joining the Global Day of Coderetreat.

The organizer of the event were me, Gabriele Lana, Giordano Scalzo and Sergio Berisso.

We decided to organize the event at the very last moment. The fact that I met Corey Haines, Peter Lind, and other guys in a pub in Stockholm two weeks before, talking also about this global event in motivated me.

It came in my mind about Lorenzo Sicilia and his FractalGarden location that I expected beeing available, so I thought that we could organize, and we did.

When back in Milan... after a rapid mail exchange with Giordano, Gabriele, Sergio and Lorenzo we had the confirmation from the location and... we made it!

The final announce was sent with a short notice, only one week before, but it went sold out in just one morning! Awesome!

We “self-sponsored” the food offering the breakfast and snacks for all day. We also get some Japanese food during the day. And of course we had some beer :D

Let's go to the day than: after a quick welcome, Gabriele Lana presented the format of the day and explained the value of the practices like coding dojo and kata.

Then we started.

The first two iterations were essentially free of rules, just to be confident about the problem, and comfortable doing programming, setting up the environment and so on.

I used an irish flute to signal the end of the iterations :)

Then in the following iterations we started suggesting some constraints like ping poing, primitive obsessions, and using immutable objects.

At the beginning we found some pairs needing help like when got stuck, and helped them and moreover tried to set up for the next iterations pairs in a way to prevent blocks.

During the 10 minutes retrospective between iterations, we encouraged attendees to share about their learning.

We closed the day with a final retrospective, and closing the circle.

Of course, we cleaned up at the end.

It was a fantastic day. And we are surely going to do it again soon.

Stop doing estimates? Yes you can!

2011-09-11T18:30:00.015+02:00

An interesting session of the Ale2011 is from Angel Medinilla, about the easy way to stop estimating.

Here are my thoughts after attending the session.

The topic originates from a quite simple concept: doing estimates needs time, which is a costs. If they are not needed, they should be considered a waste, to be eliminated, as David J. Anderson stated as well, some times ago.

His finding is that the estimates are actually not needed and he explained why.

This is my short way to come to that conclusion (not necessarily the same as was presented in the session by Angel).

Estimates are, normally, considered useful because they let us "forecast" how much can be delivered within a certain, generally short, period of time.

Well, that's not what a Product Owner really want. What is needed, actually, is not just a short term "forecast", but rather a long term "projection": a reliable release plan. And that plan can be obtained by the teams who know their velocity (usually in term of number of story points per sprint).

But, wait a moment. What if we try to get this projection just counting the features instead of the sum of their estimated size (story points)? It would be like just giving to all the stories one story point.

The fact that the story sizes may be of different sizes doesn't matter so much.

I guess that a statistician would say something like: let's just count the stories released in the past sprints, and we have an unbiased estimator of the velocity of the future sprints. It's true if the sprints are “regular” enough (i.e. the story sizes are equally distributed over the sprints) and the average of the velocities doesn't change over the sprints.

However, beside the above long-winded statement, we may just consider that it is ok also for another reason. The stories are actually small, so though counting stories (instead of summing their estimated size) will introduce a bias, that bias would be small as well.

So I am almost convinced but... wait a moment!

What about the other outcomes from the estimation activity? The conversation on the scope that you have while estimating, say, playing poker planning game?

A "mainstream" opinion is that estimation permits a conversation about the scope, giving the Product Owner important feedback about the possibility of splitting stories, clarify their scope, or modify their priority.

However stopping doing estimates could be still reasonable. Sometimes there is no need to discuss so much and so on... because may be they are perfectly clear to everybody, (and there is still room for a conversation when splitting in sub-tasks)

That could work, at least for a while, but something can change: perhaps there will be new team members, or the product may change as well, or even the customer needs may change. So in all this case, estimation can be a good exercise to let the team gel, and let emerge critical issues.

Anyway, this is just my idea about the session, and I can't remember everything from it, so if I misinterpreted the meaning, or skipped some important parts, I apologize.

Back on topic... nothing is forever. Every context is different from another, so what is good sometimes, sometimes it is not.

If during a retrospective the team suggest skipping estimation, we know that it could be perfectly reasonable and consistent even for the Product Owner, so we can give it a try... and then check.

Smettere di stimare

2011-09-10T20:25:00.011+02:00

Una presentazione interessante dell'ale2011 è stata quella di Angel Medinilla, sul modo piu' semplice per smettere di fare le stime.

L'argomento parte da un concetto semplice: fare delle stime è una attività complessa che occupa del tempo, e quindi, se non è necessaria è un waste da eliminare, come ebbe a suo tempo modo di dire anche David Anderson.

La tesi è appunto che le stime non sono necessarie.

Come fare a stabilire che non lo sono?
Una interpretazione che si da all'utilità delle stime è che queste consentirebbero di avere una "previsione" su cosa si riesce a rilasciare in un certo periodo.

In realtà più che un previsione quello che serve è una "proiezione": un piano di rilascio affidabile che possono per esempio dare i team che conoscono la velocità (come numero di story points per sprint).

Ma questa proiezione la si può ottenere anche senza fare le stime. Basta assumere che anziché misurare gli story point, si misurano le user story stesse rilasciate, come se avessero tutte peso unitario.

Non importa che le storie possono avere delle grandezze differenti. Lo statistico che è in me (ma vorrei avere una conferma più autorevole) su questo punto direbbe: il conteggio delle storie negli sprint passati è uno stimatore corretto (unbiased) della velocità degli sprint futuri, se la grandezza delle storie è distribuita allo stesso modo in tutti gli sprint e la velocità media è costante, rispetto agli sprint.

Poi, a livello pratico, diciamo che le storie già di per sé devono essere piccole, quindi, anche se fosse rilevante, l'errore potenziale tra una stima virtualmente costante (peso unitario) ed un valore (size) che è sempre piccolo, è comunque limitato.

Sotto questo aspetto, la tesi dello smettere di stimare è convincente, anche se...

che cosa diciamo del beneficio che si ha dalla conversazione che si fa stimando, per esempio attraverso "cerimonie" come il planning poker game?

Secondo il pensiero mainstream infatti tra i vantaggi dello stimare le storie c'è il fatto che risulta possibile ingaggiare una discussione proficua che riguarda lo scope, che può aiutare il Product Owner a chiarirle, modificarle, dividerle in più storie, o cambiarne la priorità.

Può darsi invece il rinunciare a fare delle stime sia effettivamente un'ottima cosa, per esempio per team ben rodati che lavorano su un prodotto già noto, ma qui è come se ci stessimo spostando su un qualcosa di più definito, dove la generare molte informazioni non è più necessario.

Ma le cose poi cominciano a cambiare: i componenti del team cambiano, cambiar il tipo di prodotto, e per questo potrebbe essere utile una discussione che coinvolga anche la grandezza delle storie, almeno come espediente per parlare anche del loro vero scope.

Comunque, niente si può dare per scontato. Ogni contesto è diverso, e quindi quello che va bene per uno magari non va bene per l'altro.

Quindi l'unica cosa è provare e... verificare.

Unplanned items, velocity and prisoner check-mark tecnique

2011-09-03T16:45:00.008+02:00

(note added: I'm going to write a short version of this post later. No need to read all of it now then)

This post is about a way to give visibility on what is happening during the sprint, including the "unplanned items", using an unplanned items burn up, measuiring the actual time by "prisoner metrics" check-marks, and having not just the velocity in term of total item of the sprint, but also the the "net velocity", calculated considering the time actually available during the sprint.

Rearranging the items for the gap between actual average velocity, and estimated, the team can effectively answer to the question "what went wrong".

We will able to see:

- actual time spent in working on the item.

- actual time spent on unplanned items.

- the actual velocity of the sprint, and a projection of what that velocity could have been if we didn't have unplanned items. This is using the "net velocity".

- at the end of the sprint we may have also visibility of what are the tech area we were late, and some guesses of why, particularly using information from the skill matrix.

The team is not supposed to add anything to the sprint, but that happens anyway: fixing bugs coming from the previous sprint, attending important meetings, or having some slack time. That actually modifies the container.

If we can't get rid of unplanned items, at least let's have visibility about.

Instead of aborting sprints, or, worst, tending to hide what's really happening, or (better) using focus factor tecquique, I'd suggest an alternative that consist in making visible:

- the actual time spent in any item

- the burn up of the time spent in unplanned items.

At the end of the sprint it can be showed where there is the need of improve, distributing the item colored with their technology area, with the rank of the skill of who worked on what items.

Here we can see a simulation of sprint:

We have a 10 days sprint of a "team" of two member (just for simplicity), and an estimated velocity of 10 story point (i.e. 0.5 story point for man/day)

(Please, note that I am not dealing so much about tasks and user stories. In the first part of the post the items we could consider them much more as they were user stories)

Here is the taskboard at the day 0:

The A and B item are selected for "doing":

After one day, we use the "prisoner metrics", that simply means using check mark to visualize the time spent on any item:

After one day, nothing changes, except that we add another checkmark to both the items:

At the beginning of the fourth day, item A is done, another mark is put on it (so the information about how much days was taken is consistent).

...the item C is in doing now:

Another day passes. And item C is check-marked appropriately:

Day 6: B is finished, it has another mark (and a cross mark as well, a big cross mark has to be put each 5 working days), and the item D is checked out.

Unfortunately, during the day an unplanned item is added and the C activity is interrupted. We track it putting that activity over C, in the following way:

The question now is what about the burn down and the unplanned item.

The burn down will probably be flatter, but we may not know the reason, then a new "burn up" chart will be useful to show how much time is being subtracted from the sprint.

In this new graph the Y axis value are based on time, and not in story points. In fact we are not estimating the new items. There is no need for this.

Another day passes, and we mark the unplanned item with a checkmark as well, and what we do with the C that is still there, unfinished, though one day passed anyway? We decide to checkmark it anyway with a different color (red). And the burn up tracks the time:

Day 8. Same song:

Day 9: we realize that D is finished.

... so the activities can be parallelized:

Day 10: the unplanned activity is done:

One of the two guys is free, and to is (legitimately) taking a slack. We make evident this as well, so we will be able to consistently count all the checkmarks at the end of the sprint (for example about counting the actual man day available in the sprint).

Day 11. All is done, and the Sprint is at the end:

What we can see here:

- the amount of the black checkmarks is the total of the man days that were available during the sprint

- the amount of the black checkmarks on the planned items is the numbers of man days spent on what was decided during the sprint plan.

- the amount of the red checkmarks shows how much time some activities have been spent in blocked state because of urgent unplanned items.

- the burn up chart, and the total of the black checkmark on the unplanned items and the slacks, they both show how much time is subtracted form the planned items.

- the burn down works is showing the remaining to work story points, as usual.

About the sprint velocity:

the velocity here is 10 story points. However what if the unplanned items and the slack were "invisible"?

1) we could have reported that in "ten man days" we have been able to work on twenty story points, so that the day man velocity is 0.5 story point.

2) we may have given the false perception that it is OK adding unplanned items during the sprint.

3) we forget to consider those data, and so we are not able to see them retrospectively in order to set some improvement direction during the retrospective meeting.

In this way we could know the Expected Value of the velocity of the Sprint if there were no interruptions.

To calculate it we just have to multiply the story points with the ratio between the available man days and the man days spent on actual planned items:

10 * 20 / 15 = 13.33

We can easily find, dividing this value with 20 (man days available on the sprint), that the average story point for man day is approx 0.66 (not 0.5).

Thus we can have a better projection on the "actual" velocity, and we can understand what would happen if we remove the interruption (as should be) on the next sprint.

We may also discuss about what really will make us slower, just in case (external interruption or bad code quality?). For example, according the the "quality of non declining velocity model" if the problem is low code base quality, the effect will be the net velocity, and of course if the problem is interruption, the effect is the total velocity.

May be we have also both, so then it is much difficult to decide what to do.

Here we can see how to reason about those data, for example when we have a retrospective.

We know how much is the gap between the average velocity and the actual velocity for any item.

For example. The A item, had an estimate of 3 story point, and toke 3 man days. According to the actual "net velocity" the expectation of story points done in three days is 0.66 * 2 = 2. So this story has a +1 respect of the estimation.

Let's make some calculations about all these actual vs estimated

(p.s. and note that thought the comparison uses time, there are no actual time based estimates).

In interesting game is setting out the items up on a X,Y axis (X is the timeline, and Y is the distribution of the gab between the actual and expected time, according to the net velocity):

(We don't care about the Y of slacks or unplanned items because are not estimated and shouldn't)

Moreover, if the item are proper tasks (instead of generic items) we can introduce more dimentions to this diagram, using color for tech areas, and symbols from the skill matrix.

(task are not supposed to have story points, but that does not matter so much. We can still distribute story points of a story to it's tasks, for instance)

So now, dividing the items per tech area (that makes perfectly sense), we can see something like:

In blue items we performed better than the others.

One of the reason could be that the people that worked on them were not so much skilled in that area. To make it evident we could have added the values taken from the skill matrix when working on that item.

Tipically each entry in the skill matrix is empty, has a dot, or a star.

Wen we rearrange the item at the end of the sprint we could have something like follows (I replaced the dot with a 'x'):

It's perfectly clear that the guys that worked on the area that performed well, are skilled in there, and that may be the most likely reason for the performance, so we don't worry too much about, except that we may have some new challenge, as improve some skill in some area where we are weaker.

In other cases, for example when the skill matrix data are randomly distributed on the Y axis, our finding can be different (for example that the skill matrix need to be updated realizing that our team became more cross functional).

Some actions that can be taken about the relevance of some weakest area, is the re-estimation of components that are more closer to some area where we realized are weaker than expected.

Or we may adjust the skill matrix in a more realistic way, and so on...

Non era nello Sprint Backlog: item non pianificati, e tecniche del prigioniero

2011-08-25T14:45:00.073+02:00

-Una misura è una riduzione di incertezza espressa quantitativamente sulla base di una o più osservazioni. - (Douglas W. Hubbard - How to Measure Anything)

- Ogni Buon Regolatore di un sistema deve essere un modello di quel sistema (R.G. Conant, W.R. Ashby)

Vediamo qualche modo per visualizzare informazioni "non standard" sulla taskboard.

Ciò che non è stato deciso in fase di Sprint Planning Meeting, proposto dal P.O. e stimato dal team, non dovrebbe esistere.

Tuttavia a volte garantirlo è difficile, c'è il "firefighting", emergenze non rimandabili che sopraggiungono. Come si può fare a mantenere comunque consistenti le informazioni degli information radiator e le relative misure?

Mettiamo di avere nello sprint backlog quattro items per un totale di 10 story point.

Diciamo che il team è composto da due persone (poche rispetto allo standard, ma è per semplificare) e che lavora su generici "item" dotati di stima in story point.

Giorno 0. Nello sprint backlog ci sono quattro item:

Al primo giorno vengono selezionati e spostati in "doing" gli item A e B:

Passa un giorno. La taskboard si presenta come segue:

Gli item che si trovano in doing sono stati marcati con una barretta per indicare che è passato un giorno, un po' come farebbe un prigioniero in una cella.

Nel giorno successivo le cose restano invariate, e viene aggiunta un'altra barretta ad entrambi gli item, mentre il burn down resta piatto.

All'inizio del quarto giorno risulta che l'item A è terminato, vengono sempre aggiunte le barrette per il tempo passato in "doing", il burndown si abbassa di tre punti...

...e si mette l'item C in doing:

Passa un altro giorno, vengono aggiunte le barrette agli item che sono in "doing":

Il giorno 6 risulta terminato l'item B, e quindi viene preso in carico D:

Durante la giornata C viene interrotto per far posto ad una attività imprevista (Unplan):

Mediante un nuovo grafico "burn up" verrà tracciato il tempo che si spenderà in queste attività "unplanned":

A differenza del burndown, in questo grafico i valori dell'asse Y sono espressi in unità di tipo tempo-uomo, e non in story point.

All'item C, che è rimasto in sospeso perché interrotto, viene aggiunta comunque una nuova barra, questa volta rossa, per mettere in evidenza la quantità di tempo in cui l'item è rimasto bloccato.

Sì continua allo stesso modo al giorno 8:

Nel giorno 9 l'attività D è terminata...

... quindi le attività in corso posso essere parallelizzate:

Al giorno 10 l'attività unplanned è terminata:

Uno dei due membri del team è libero, e potrebbe aiutare l'altro componente del team o approfondire qualche argomento. Per "quadrare" i conti, si introduce un item fittizio "slack".

Il giorno 11 finisce lo sprint, e le attività sono tutte concluse:

In sintesi:

- il totale delle barre nere è il numero di giorni/uomo che abbiamo avuto a disposizione durante lo sprint

- il totale delle barre nere degli item pianificati è il numero di giorni uomo spesi per quanto deciso durante lo Sprint Planning.

- le barre rosse rappresentano il tempo in cui certe attività sono rimaste "bloccate".

- il burn up chart, oppure il totale delle barrette nere degli item non pianificati e degli slack, mostrano il tempo uomo speso in attività non pianificate.

- il burn down funziona al solito modo.

Sulla velocità:

se gli item non pianificati e lo slack fossero rimasti "invisibili", avremmo detto che la velocità del team è stata di 10 story point, ma in realtà dei 20 giorni uomo a disposizione nello sprint, solo 15 sono stati utilizzati per gli item pianificati, altri 4 per un item non pianificato, e uno per lo "slack time".

Possiamo ricavare la "velocità netta".

Perché dovremmo farlo?

La velocità netta permette di conoscere il valore atteso di quella che sarebbe stata la velocità totale se lo Sprint non fosse stato "inquinato", e quindi rende confrontabili le velocità di sprint diversi.

Un modo rapido per calcolarla è moltiplicare il numero di story point portati a termine per il numero di giorni uomo dello sprint diviso il numero di giorni uomo effettivamente utilizzati per i planned items: 10 * 20 / 15 = 13.33

Il numero medio di story point per giornata è 1.33. Siccome il team è di due sole persone, dividiamo per due per ottenere il numero medio di story point per giorno uomo: 0.66.

Oltre ad avere proiezioni sulla velocità "reale", si possono incrociare queste informazioni in altri modi, per esempio per discuterne in una retrospettiva.

Per ogni item sappiamo di quanto si è discostata la velocità rispetto alla media.

Per esempio per l'item A, stimato in 3 story point, la velocità effettiva è stata di 3 giorni uomo. La media degli story point in tre giorni è 0.66 * 3 = 2. Quindi per quella storia un "bilancio positivo" di 1 story point.

Questi valori possono essere aggiunti in rosso nelle user story.

Da notare che si compensano a vicenda e dunque la loro somma deve fare zero.

Si possono poi ordinare su una"timeline", sull'asse X rispetto al tempo, e sull'asse Y rispetto allo scostamento dalla media, per avere una visione di come sono distribuiti nell'arco dello sprint.

(La collocazione degli item di tipo unplan e slack è arbitraria rispetto all'asse Y.)

Con la colorazione rispetto alle aree tecnologiche, possiamo anche vedere la correlazione di tali valori rispetto alle aree tecnologiche stesse.

Per questo tipo di analisi anziché di item di tipo user story, parliamo di task.

I task sono legati alle componenti tecniche. In teoria non sarebbero da stimare in story point, ma possiamo assumere che "ereditano" il numero di story point attribuito dalla user story a cui appartenevano.

Dalla distribuzione dei colori rispetto all'asse Y si può avere una visione di insieme su alcune criticità dello sprint:

Sembra che gli item blu siano andati meglio del previsto, a differenza dei gialli.

Per spiegarcene le ragioni possiamo integrare in queste viste anche valori relativi alle competenze della skill matrix.

Tipicamente una entry nella skill matrix è vuota, oppure ha un punto, o un asterisco.

Quando un componente del team lavora su un task di una certa area tecnologica, ricopiamo sul task stesso il suo grado di competenza relativo, come da skill matrix, cioè un asterisco, un punto o niente.

Nel redistribuire gli item alla fine dello sprint abbiamo qualcosa come:

Si vede che gli item che sono andati meglio della media sono stati portati a termine da persone che secondo la skill matrix erano i più competenti in quell'area. Questo non sorprende.

Le informazioni che emergono possono essere interpretate in diversi modi: per esempio per ri-aggiornare la skill matrix, per verificare se non siano state sottovalutate le complessità di particolari aree tecniche, e così via...

codebreaker in javascript + underscore.js

2010-12-15T14:54:00.006+01:00

Prosegue la versione in più linguaggi del codebreaker kata.
Ora è la volta di una versione in javascript, che utilizza come ambiente jspec e rhino., e usa la libreria underscore.js
Tali ambienti sono installati in una macchina virtuale Ubuntu.
Per i primi 10 secondi c'è un po' di blink dello schermo, e la musica di sottofondo parte dopo qualche minuto.
Lo screenacast include la parte di inizializzazione del progetto, per i primi due minuti e mezzo, il tempo netto di esecuzione è poco più di 10 minuti.

La sequenza dei test è la seguente:
(nota: tutte le funzioni che iniziano con _. fanno parte della libreria "underscore.js")

time, guess secret: [commento] -> answer

3:00 - "xxxx" "rgby": nessun match -> ""

3:25 - "yxxx" "rgby": un match imperfetto (prima posizione)-> "n" (risolto con un if)

3:55 - "xyxx" "rgby": un match imperfetto (seconda posizione) -> "n" (risolto con un or aggiunto all'if precedente)

4:10 - . refactoring -> i due or dell'if precedente vengono trasformati in un ciclo for su tutti gli elementi del guess (e questo significa che il codice sarà in grado di gestire anche i singoli match imperfetti in terza e quarta posizione, anche se non viene scritto nessun ulteriore test di questo tipo).

4:35 - "byxx" "rgby" : due match imperfetti -> nel ciclo for, in caso di match, si accumula il risultato da restituire (concatenazione di 'm'), anziché uscire immediatamente. Questo intuitivamente risolve altri casi di match imperfetti (di diverso numero e diverse posizioni) e quindi non vengono aggiunti altri casi di test simili.

0:51 .refactoring -> il ciclo for viene rimpiazzato dal costrutto _.each

5:30 "yyxx" "rgby" -> un solo match "m" anziché due, perché la 'y' occorre una volta nel secret. Soluzione: ogni volta che viene contato un match, il relativo colore viene rimosso dal secret stesso, così non verrà più contato. (nota: non è così banale "dedurre" questo "requisito" imo).

6:30 .refactoring: viene estratto il metodo che restituisce, da una stringa, la stessa senza uno specifico carattere (nota: lì introduco un bug perché aggiungo la chiamata al nuovo metodo senza cancellare il codice che esegue la rimozione, quindi la rimozione viene fatta due volte: il bug viene scoperto e corretto più avanti.

7:22 .refactoring -> trasformo la chiamata _.each() nella chiamata _.reduce(). Questo consente di eliminare l'uso di una variabile di accumulazione del risultato (toReturn) e di tagliare due righe. (nota avrei dovuto accorgermi del baco descritto sopra perché la riga in questione ha una lunghezza sospetta)

8:02 .refactoring -> l'intenzione è di separare la logica del conteggio del numero dei match dal fatto di volerlo rappresentare in una stringa di 'm'. Dal metodo mark così creato, ne creo uno nuovo (countNonPositionals), che anziché accumulare in una stringa tanti 'm' quanti sono i match non positionali, li accumula in un numero (a questo punto lui non sa come sarà presentato il risultato)

8:16 .refactoring -> eseguo una combinazione di _.reduce e _.range applicata alla funzione countPositionals per ottenere una concatenazione di m pari al numero di match non positionali (e questo sostituisce l'attuale funzionalità della "mark")

8:51 .refactoring -> introduco un metodo apposito che trasforma un numero in una sequenza di caratteri

10:00 "rxxx" "rgby" : match perfetto in prima posizione -> duplico i metodi mark e countNonPositionals in positionalMatch e countPositionals. Usano la stessa logica, salvo accumulare le 'p' al posto delle 'm' e usare la logica di confronto posizione per posizione, anziché la logica del "contiene". Viene anche tolta la chiamata alla rimozione dei caratteri che matchano (comincio ad accorgermi che qualcosa non va, a riguardo della logica di rimozione duplicata, ma non metto ancora a posto il bug ereditato nel punto originario, cioè nella countNonPositionals).

11:30 refactoring del test (o correzione di errore nel test stesso) -> devo chiamare la positionalMatch anziché la mark (che solo dopo unificherà entrambe le logiche).

11:36 nuovi test: match posizionale in seconda posizione e doppio match posizionale (non cambio nulla del codice perché già passa questi test)

12:13 il test che chiama la logica del match posizionale, ora chiama la mark stessa (che fin'ora contava solo i match non posizionali). -> inizio a concatenare le logiche delle due chiamata (non chiamo esplicitamente la positionalMatch perché in teoria è destinata a scomparire), mi accorgo che anziché restituire "p" viene restituito "pm" e presumo che il non posizionale "intruso" 'm' sia un riconteggio come "match non posizionle" di quello precedente. Posso risolvere elimino dal conteggio dei non posizionali, il numero dei posizionali. Lo faccio clonando la countNonPositionals in countAnyMatch, e poi trasformando la countNonPositionals in modo che restituisca il valore della chiamata a countAnyMatch cui viene sottratto il risultato della chiamata a countPositionals (togliendo cioè il falsi non posizionali).
Da lì in poi ci sono vari casi di test significativi che passano, dal che si comincia a pensare che siamo arrivati all'algoritmo giusto, salvo la correzione del bug, come da punto seguente:

14:45 "rryy" "yyrr" -> mi aspetto quattro match imperfetti, ne vengono fuori solo due a causa del bug della doppia rimozione in caso di match nella countAnyMatch (ex countNonPositionals). Dopo un attimo di incertezza elimino il bug.

Conclusioni: è un po' più complicato della versione originaria in C#, ma forse il risultato finale è più espressivo, almeno per quanto riguarda la funzione "mark".
È quasi completamente stateless, e l'uso della libreria _. avvicina la soluzione a quello che si farebbe tipicamente con linguaggi funzionali o estensioni come LinQ.

In teoria non è previsto che in un "kata" con un bug introdotto e poi corretto, ma è comunque interessante.

Nel libro di Rspec lo stesso problema viene trattato in vari modi. Sarebbe da riguardare per qualche confronto.

Ciao.

NUnit Growl Notification

2010-11-12T12:42:00.009+01:00

This is a simple explaination of the NUnit growl notification AddIn.
https://github.com /tonyx/NUnitGrowlAddIn

It has been tested on NUnit 2.5.5. and NUnit 2.5.7.

Here is the main documentation about writing NUnit plugins:

http://nunit.org/index.php?p=nunitAddins&r=2.5.8

As far as I know to build it correctly you need to add the proper versions of nunit and growl assemblies in the lib directory. In this way I got working builds for Nunit 2.5.5 and 2.5.7.

I tested them in two differenet Windows 7 machines, 64 bit arch.

The target framework is 3.5, and works under 4.0 as well.

The binaries included are for NUnit 2.5.7.

However I included prebuild binaries for Nunit 2.5.7.

I encourage people to rebuild it and test in other platforms.

I found an equivalent project, but no compatibile with other version but Nunit 2.5.5.

I need those tools for games like doing katas with continuous test/build and so on.

Another useful project at it is autobuild:

http://code.google.com/p/autobuildtool/

Hopefully stuffs like those will be used also when writing production code, and no just katas, to make you focus on TDD cycle.

Here is, essentially, how does it work:

the interfaces implemented are Iaddin and EventListener

the constructor instantiates the notification types and register them to the growlconnector
the Install method actually registers the instance in order to make it recognized as an EventListener for nunit related events (suitestarted, teststarted and son on...)
the custom behaviour (notification to growl) is coded in methods like RunFinished an so on..

My aim was to visualize, after each build (actually continuous build, using autobuild):

an ok, greeen, notification when all the test passes, with the number of test passed
a non ok, red, notification when at least one test fails or has an error, with the number of failures and errors, and the number of total tests as well
a non ok, red, notification for each failed test, with the actual and expected values specified.

So there will be one green notification of the number of failing and error tests +1 after each build (actually, each source file saved, if using autobuild).

In normal tdd ciclye you will get one green notification or two red notifications, that should be a good reminder that you are supposed to actually work on the failing test to get rid of them.

Some screenshots:

A screenshot of a failing test:

A two and half minutes video:

Nunit AddIn for Growl from tonyx on Vimeo.

Thanks for reading, feedback are welcome.

Codebreaker in F#

2010-10-25T22:37:00.013+02:00

(english version of this post comes later, may be :D )

Ho studiato un po' di F#, finalizzando lo studio ad un kata, quello del codebreaker (marking guess), già a suo tempo affrontato in C# (http://www.vimeo.com/13072671) (ma che non ho mai commentato).

Ecco il link di questa nuova versione in F#: http://www.vimeo.com/16177730

codebreaker, marking guess, in F# from tonyx on Vimeo.

Imparare un linguaggio nuovo è stato uno dei miei buoni propositi quando sono tornato dalla Software Craftsmanship conference tenutasi a Bletchley Park il 7 ottobre. A proposito: non ho scritto nessun post sull'argomento. Forse è un po' tardi per questo, vabbe', sopravvoliamo.

Un commento, a grandi linee su questo codebreaker in F#

Uso un piccolo wrapper (gu' presente nel file sorgente) che consente l-uso stringhe anziché liste in modo da poter scrivere "xxxx" anziché ['x';'x';'x';'x'].

Oppure un test del tipo AssertEquals(['m'] , guess ['y'; 'x';'x';'x'] ['r';'g';'b';'y'] ) lo posso scrivere così shouldBe "m" guess "yxxx" "rgby"

È zucchero sintattico.

Nella sostanza: non si tratta di una mera trasposizione in F# dell'algoritmo usato nella versione C#.

Ho tentato soprattutto di sfruttare le caratteristiche di questo linguaggio ed in particolare dei costrutti ricorsivi, e poi ho fatto un po' più di refactoring, e di separazione di responsabilità (anche se penso che siano mancati alcuni passi alla fine).

Per esempio:

nel secondo test il colore corretto (ma che non è non nella giusta posizione) è il primo, e siccome uso il pattern matching [H::T] dove H è la testa della lista, viene facile usare H per la logica che mi serve ai fini del caso rappresentato dal test, e tenere la coda T per il resto (la chiamata ricorsiva).

Il codice per passare il secondo test è


let mark guess secret =
match guess with
| H::T when List.contains H -> ['m']
| _ -> []

Il codice per passare il terzo test (in cui il match è il secondo elemento, ovvero la testa della coda T) è:


let rec mark guess secret
match guess with
|H::T when List.contains H secret -> ['p']
|H::T -> mark T secret
_ -> []

Notare ce ho aggiunto il "rec" (per dire al compilatore che mark verrà chiamata ricorsivamente) ed ho eseguito la chiamata ricorsiva sulla coda (mark T secret).

Il caso aggiuntivo del doppio match si risolve aggiungendo, in caso di match, oltre alla 'p', il risultato della chiamata ricorsiva in coda (mark T secret)

Non ho intenzione di spiegare tutto il kata, e sorvolo il caso dei test sui match non posizionali perché è del tutto analogo.

Mi limito ad osservare che verso la fine un po' di lavoro viene fatto per togliere alle funzioni di match posizionale e non posizionale la responsabilità di costruire il risultato (sequenze d 'p' ed 'm') e spostarlo verso un'altra funzione, facendo in modo che suddette funzioni si limitino a contare i match, lasciando ad altri il compito di rappresentarlo con dei 'p' 'm', o come si vuole.

In soldoni, per esempio la funzione di calcolo dei match posizionali, è prima questa (che restituisce tanti 'p' quanti sono suddetti match):


let rec positionalMatch guess secret =
match guess, secret with
| H::T, H1, T1  when H = H1 -> 'p' @ positionalMatch T T1
| H::T, H1, T1 -> positionalMatch T T1
|  _  -> []

ma poi diventa questa


let rec positionalMatch guess secret =
match guess, secret with
| H::T, H1, T1  when H = H1 -> 1 + positionalMatch T T1
| H::T, H1, T1 -> positionalMatch T T1
|  _  -> 0

che appunto accumula il risultato in un numero, anziché in una sequenza.

Per la trasformazione del numero in sequenza utilizzo questo trucchetto, che mostra qualche finezza di questo linguaggio:

[1..count] |> Seq.fold (fun acc x -> acc @ ['p']) []

che più o meno potrebbe essere spiagato come:
mandare la sequenza da uno fino a count in "pipeline" ad una funzione che opera accumulando un certo valore appendendovi un 'p' e partendo da una lista vuota, e restituendo alla fine tale risultato.

In altri linguaggi sarebbe bastato forse scrivere qualcosa come ['p']*count, per ottenere la stessa cosa, ma comunque... sempre meglio che un ciclo for.

Per finire:

È facile intuire che il codice che conta i match non posizionali include nel conteggio anche quelli posizionali, cosa che non va bene nel risultato. Bisogna restituire questi match al netto dei match posizionali, che vanno indicati in modo diverso (con i 'p').

Questo problema veniva risolto (nella vecchia versione del kata) con un trucchetto: eliminando dalla concatenazione del risultato posizionali + non posizionali un numero di caratteri pari ai posizionali stessi.

Però se il risultato richiesto fosse stato invertito (prima i non posizionali e poi i posizionali) questa cosa non avrebbe funzionato.

Per prevenire questo problema è meglio fare in modo che i non posizionali siano già al "netto" dei posizionali prima di concatenarli. In questo modo si introduce minore resistenza a certi cambiamenti desiderati (come questo di invertire le 'p' con le 'm').

È un po' quanto fatto qui (anche se c'è spazio per miglioramenti), aiutati dal fatto che i match, dopo il refactoring, vengono effettivamente contati, indipendentemente dal fatto che poi verranno rappresentati con dei 'p', dei 'm' o in un particolare ordine o altro.

Ma non mi prolungo oltre, anche se da dire ne avrei.
Penso che I kata non vadano commentati. Vanno fatti, vanno visti, vanno "goduti" e, ovviamente, vanno migliorati.

Per riferimenti:

La versione di Corey Haines (con una rapida introduzione del problema)
http://katas.softwarecraftsmanship.org/?p=27 (a sua volta presa dal testo su Rspec)

La versione in IronPython di Mark Heath:
http://vimeo.com/15329417

La mia versione in C#:
http://katas.softwarecraftsmanship.org/?p=168

Qcv (Quality of non-declining velocity curve)

2010-09-15T00:38:00.008+02:00

This curve is a sort of model about how theoretically the practices are related to the quality, and how the quality is related to the velocity.

Some practices related to the quality are very obvious, code convention, pair programming, for instance.

The quality is related to the velocity because a good code base makes the next feature cheaper.
At the other side, a bad code base means that you will go slower.

The Qcv level so it is the "quality of non declining velocity", a point such that you will keep the same velocity.

Almost the same concept has been introduced under the name of the quality/speed barrier, that can be said in this way: "there is a point where below it you need to go slower to go better, but above it you go faster because you go better." (said J.B. Rainsberger in this video 00:58)

So how do we know where we are?
Doing lesser and lesser story point at any iteration, means being under Qcv, seems to me.

The main question is what to do then?
Introducing "quick fix" is not a medicine to go faster because it means corrupting the code base, so it's even worst.

Instead, some time must be spent to re-inject the lost quality.

Can you convince the p.o. to do it? It's about how to convince the p.o. to accept tech stories.
According to Henrik Kniberg, in "Scrum and Xp from The Trenches" it should be possible:

Team: “We have some internal tech stuff that needs to be done. We would like to budget 10% of our time for that, i.e. reduc focus factor from 75% to 65%. Is that OK?”
Product owner: “Hell no! We don’t have time!”
Team: “Well, look at the last sprint (all heads turn to the velocity scrawls on the whiteboard). Our estimated velocity was 80, and our actual velocity was 30, right?”
PO: “Exactly! So we don’t have time to do internal tech stuff. We Need new features!”
Team: “Well, the reason why our velocity turned out to be so bad was because we spent so much time trying to put together consistent releases for testing”.
PO: “Yes, and?”
Team: “Well, our velocity will probably continue being that bad if we don’t do something about it.”
PO: “Yes, and?”
Team: “So we propose that we take approximately 10% off of this sprint to set up a continuous build server and other stuff that
will take the pain off of integration. This will probably increase our sprint velocity by at least 20% for each subsequent sprint, forever!”
PO: “Oh really? Why didn’t we do this last sprint then?!”
Team: “Er... because you didn’t want us to...”
PO: “Oh, um, well fine, sounds like a good idea to do it now then!”

p.s. I spent some time thinking about the numbers of the example. Here is my ideas about: if the team don't do tech stories, they will keep going slower: 30 story points (instead of 80), so the focus factor will be 28% (instead of 75%).

If they will do the tech story at the next sprint, so they can come back at a normal velocity of 80 story point (focus factor 75%) they need to subtract the 10% of the time of the next sprint for it (and should do it at the beginning of the sprint to capitalize as earlier as possible this value). So there is left the 90% of the time of the next sprint doing normal stories at the normal velocity, so the number of story points will be 72, instead of 80, and thus the focus factor should be 67.5% (not far from the suggested value of 65%, actually), instead of 75%.

Dilemma del prigioniero iterato e principi agili

2010-09-12T11:24:00.007+02:00

Il modello del dilemma del prigioniero mostra che la strategia più razionale, “defeat”, non è quella ottimale, tuttavia nel dilemma del prigioniero iterato esiste un evidente vantaggio usando strategie “irrazionali” (ma il termine più fortunato è “superrazionali”).

Qui abbiamo una interessante rappresentazione visuale del processo.

I metodi agili sono secondo me un banco di prova interessante di questo modello.

Nel manifesto agile si parla di collaborazione, e nei metodi che si ispirano a questo manifesto sono previste le iterazioni, quindi, considerando una iterazione come una mossa, le strategie “superrazionali” del dilemma del prigioniero, basate sulla possibilita' di cooperare anche senza essere sicuri che tale cooperazione sia corrisposta, sembrano adeguate.

Per esempio:

Il customer si aspetta che ad una prima iterazione venga portata a termine la feature 'A'.

Il customer la descrive nel suo linguaggio, il team la interpreta, e la implementa.

In linea di principio la descrizione che fa il customer della feature non potrà mai essere abbastanza precisa da non generare equivoci, altrimenti la descrizione stessa sarebbe talmente "effettiva" da rappresentare un "programma" (cosa che spetta al team).

Di principio sembra ineluttabile che il team alla fine dell'iterazione possa scoprire che quanto implementato non e' quello che voleva il customer.

La strategia “defeat” del customer sarebbe quella di innescare un conflitto basato su cose in linea di principio indimostrabili, o iniziare facendo descrizioni abbastanza vaghe da aumentare la probabilita' che qualcosa vada apparentemente storto, in modo da puntare ad un “blame game” in una posizione di vantaggio.

La strategia “defeat” del team sarebbe invece quella di implementare l'interpretazione a loro più comoda della feature 'A', e non cercare di capire veramente le intenzioni del Customer, o di non proporgli gli strumenti (non necessariamente tecnici, vedi cap. 4 di “Scrum and Xp from the Trenches”) più adatti per ridurre le incomprensioni.

(aggiungiamo pure la strategia “superirrational” del Customer che rifiuta di adottare questi strumenti, o quella “superirrational” del team che propone questi strumenti ma senza coglierne le vere ragioni, - vedere anche alla voce “cargo cult”)

Usare sistematicamente il “defeat” nel modello del dilemma del prigioniero reiterato è una strategia perdente, e dunque è più accettabile per entrambi la strategia cooperativa dell'assumere il reciproco interesse a capirsi, e migliorarsi, cosa che rientra nei principi del manifesto agile e, a maggior ragione, del manifesto for software crafsmanship.

Washing the dishes using Kanban

2010-09-12T00:15:00.006+02:00

No irony. I think I experienced the Kanban principles when I was involved in washing the dishes in a restaurant. We were two of us committed in that activity, and there was no strict task division, though, nobody know why, it ended that I used to dry and the colleague to wash. Here is a picture of the phases:

It's quite obvious that there is the need to make sure that the less time as possible is spent from the beginning and the end of all the phases (lead time), that there is a natural wip limit given by the limited space available, and that a good indicator of problems are the "air bubles", and it's also obvious how to detect when we get close to the wip limit, because of the limited physical room available. Here I can show a case of reaching the wip limit because of a context switch.
In my case the context switch used to happen when I were assigned the task of clean some mussles (which means, remove the linen), in order to be cooked. I had to interrupt my activity for a while to tho this. When I returned to the normal activity, the typical situation that I used to find was as follows:

There is a bubble air in the "ready" state because while I was busy elsewhere, nobody was drying the dishes, and it's evident that it was a problem: the system was releasing nothing and so any activity related to the previous phases did not produce any value yet. The wip limit was reached for the items before the ready state.
A mind set focused on the goal of getting things done mainly in order to produce a result, no matter how, could be taking a look at the state of the system, and act consequently, instead of just doing anybody some predefined activity (I wash, you dry, any other consideration is out of my business).
From this point of view, for me the issue is not about if Kanban is agile or not , but, moreover, that the system can show dysfunctions that you should care about as a whole team, in other word kanban is just a messenger, and so being agile or not is not a about kanban itself, it's about you.

In the same way, it's clear that this does not change "directly" the nature of the specific operations, that you cannot avoid: you have to pass those phases, unless you change completely the method - i.e. adopt a washing machine.

There were no chance to do differently to optimize because we were not so many worker, and you can't predict how many context switches could happen for me or whoever, and so you had to "see" things, get the feedback and act consequently.

Obviously, in the above example there were no need of any cards or board, because there is no need a symbolic representation to communicate something of a system that the system by itself already shows, but assuming you deal with situations where this is not true, so the system can't communicate directly his state, then you need a symbolic representation of it, and Kanban does it.

Again, obviously, Kanban does not represent a working method, but with Kanban (and with Scrum as well) you have better chances to get the information needed in order to improve, and, then, may be, also pick up practices and methods that fit better.

Lavare i piatti con Kanban

2010-09-11T21:45:00.009+02:00

Non c'è ironia. Credo di aver sperimentato il concetto di Kanban quando lavavo i piatti in un ristorante. Eravamo in due in questa attività. In teoria non c'era alcuna divisione del lavoro specifica, anche se alla fine, non si sa perché, era più facile che io asciugassi e il collega lavasse. Ecco una immagine delle varie fasi:

è abbastanza ovvio che è necessario far passare il minor tempo possibile tra l'entrata all'uscita dal sistema (lead time), che esiste un wip limit naturale dovuto a motivi di spazio, e che un buon indicatore dei problemi siano le "bolle d'aria" ed il superamento del wip limit, che accadono per esempio in casi legati al context switch. Nel mio caso il problema del context switch era che periodicamente ero chiamato a pulire delle cozze (che significa rimuovere il bisso), perché fossero pronte per essere preparate in qualche piatto. Quando riprendevo l'attività dei piatti ecco un po' la situazione che trovavo:

C'è una bolla d'aria nello stato "pronto" perché nel periodo in cui ero impegnato altrove i piatti non venivano asciugati ed è abbastanza evidente che questo era un problema: il sistema non stava rilasciando nulla e dunque ogni attività che nel frattempo era stata fatta relativa alle fasi precedenti non aveva (ancora) prodotto alcun valore. Il wip limit naturale era lo spazio fisico occupato dalla pila di piatti da asciugare.
Un mind set focalizzato sull'obiettivo di fare le cose per produrre un risultato, non importa come, avrebbe dovuto essere quello di vedere lo stato del sistema, e agire di conseguenza, anziché applicare una mentalità basata sulla semplice divisione dei compiti (io lavo tu asciughi). Da questo punto di vista per me la questione non è tanto se kanban sia agile o meno, ma piuttosto che è utile perché sulla base delle disfunzioni che kanban mostra, si possono prendere dei provvedimenti, che però necessitano di per sé di un mind set collaborativo, comunicativo, ovvero agile.

È altrettanto chiaro che ciò non cambia "direttamente" la natura delle operazioni specifiche, che sono ineludibili: non puoi fare a meno di quelle fasi, a meno di non cambiare completamente metodo - es. dotarsi di una lavastoviglie.

Non si poteva fare molto diversamente per ottimizare perché le persone erano poche, e non era prevedibile quanti context switch ci sarebbero stati per me, o per chiunque altro, e dunque era necessario "vedere" le cose, ed ottenere e gestire il feedback che da questo stato giungeva, ed agire di conseguenza.

Ovviamente nell'esempio in questione non sono necessari i cartellini dato che non c'è bisogno di una rappresentazione per comunicare quello che il sistema già comunica di per sé, ma supponiamo di avere altre realtà in cui il sistema non sia in grado di comunicarle lo stato direttamente, allora c'è bisogno di una rappresentazione simbolica di questo sistema, ed la Kanban board riesce a darla.
Naturalmente non è che Kanban rappresenti un metodo di lavoro, ma piuttosto con Kanban (così come con Scrum) si ottengono probabilmente le informazioni necessarie a migliorare, e dunque anche a scegliere le pratiche e i metodi più adeguati.

Scrum e XP dalle trincee

2010-08-08T19:26:00.009+02:00

Ho tradotto, con Luca Minudel, "Scrum and XP from the Trenches". Un racconto agile vissuto sul... fronte di guerra, per usare una fortunata metafora dell'autore Henrik Kniberg. È un testo che merita di essere riletto. Un messaggio molto chiaro di questo libro è che Scrum non è una ricetta e non è un insieme di 'best practices' da applicare come da manuale aspettandosi che poi tutto funzionerà come un orologio. Al contrario: è un insieme di strumenti che consentono di misurarsi e migliorarsi nell'ambito di un processo empirico. Sta a chi usa Scrum cercare di capire come utilizzare i suoi semplici tools, come favorire i miglioramenti necessari nel particolare contesto in cui si trova. E il contesto è sempre unico, come ci ricorda Henrik quando sottolinea che "io stesso potrei applicarlo in un modo diverso se mi trovassi in un contesto diverso".
Consiglio di leggerlo, o dirileggerlo.

p.s. per commentare la traduzione, contattatemi pure, qui sul blog oppure ad uno dei miei indirizzi di email tonyx(at)yahoo(dot)com e tonyx1(at)gmail(dot)com

Il testo è disponibile su InfoQ: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
p.p.s. il "compagnio di pair" della traduzione, Luca, agilista di lunga data, è invece contattabile sul suo blog: http://blogs.ugidotnet.org/luka/Default.aspx

My Codebreaker, marking guess on www.katacasts.com

2010-07-06T22:58:00.003+02:00

CodeBreaker marking guess revised from tonyx on Vimeo.

By Corey Haines in Katas, Software Craftsmanship

"After a long break, we have a fantastic katacast to present to you. Antonio Lucca contacted me with a new, C# version of the codebreaker kata. I started watching it and was blown away. Is that C#? In Vim? With autotest-like functionality? Super sweet! Without more rambling from me"

link on www.katacasts.com

Quality of non declining velocity curve

2010-04-30T16:39:00.010+02:00

This curve is a sort of model about how theoretically the practices are related to the quality, and how the quality is related to the velocity.

discussion about quality scope resources time variables

2010-04-29T14:05:00.005+02:00

Discussion about the effect of quality on the process, for example defining the quality as the variable that affect the speed, and the independence, of implementing the next features. Inspired by the speed quality barrier of J.B. and quality of non decreasing velocity (Qdv) of @keith_b models. The claim is that there is sustainable development while being over the quality of non declining velocity level, and so there could be a discussion about the fact that some practices are economically justified if it can be proved that they make possible being over the Qdv.

four variables

View more presentations from tonyx.

bowling kata ocp way (extended comment)

2010-03-22T00:23:00.011+01:00

Some more notes about my "ocp bowling kata".

An execution of a generic bowling is a serie of frames, each composed of some rolls.

Se sequence {5,5} is allowed in a single frame. The sequence {10,1} is not, because if the first roll in a frame is 10 then the frame is over.

To model those validation is used the Delegates technique, introducing constraints witch return true or false on a frame to check if the frame is valid according to some specific bowling instance.

Here there are the constraints needed for the plain ordinary frames from index 0 to 9:


Constraint sumOfAllRollMustbeLessThanTen = 
    (x => x.Rolls.Sum() <= 10);
Constraint ifFirstRollIsTenThanTheFrameIsOver = 
    (x => (!(x.Rolls[0] == 10) || x.Rolls.Count == 1));
Constraint ifFirstRollIsLessThanTenThenThereIsAnotherRollInTheFrame = 
    (x => (!(x.Rolls[0] < 10) || x.Rolls.Count == 2));

Those constraints are composed (by &&) and injected using the call: SetConstraintForFrame().

There is the possibility that a frame with different index has different constraints.
The 10th frame in the terrestrial bowling in fact has different constraints:

        
Constraint sumRollsNoHigherThanThirty = 
     x => x.Rolls.Sum() <= 30;              
Constraint ifFirstRollIsTenThanThereIsAtLeastAnotherRoll = x =>        
    !(x.Rolls[0]==10)||x.Rolls.Count > 1;

Constraint ifSecondRollIsTenThenThereIsAnotherRoll =
    x => (!(x.Rolls.Count > 1 && x.Rolls[1] == 10) || x.Rolls.Count == 3);

(see the factory)

Note that the following logical rule has been used:
if A then B is the same as !A || B

There are also rules to calculate the score and the bonus.

The Spare rule says that there is a bonus given by the next roll, and the Strike rule returns as a bonus the next two rolls.

Score is divided by the plain score and the bonus, so also the plain score rule (generally given by the rolls) can be injected.

I still don't know if unit test should allocate frames or single rolls.

At the moment there are both in the tests .

For instance to compute zero score using frame is as follows:



        [Test]
        public void TestAllZeroes()
        {
            Frame frame = new Frame(0,0);
            for (int i = 0; i < 10; i++)
            {
                terrestrialGame.AddFrame(frame);
            }
            Assert.AreEqual(0, terrestrialGame.Score());
        }

and the following is the equivalent that uses rolls:




        [Test]
        public void TestAllZeroesByRolling()
        {
            for (int i=0;i<20;i++)
            {
                terrestrialGame.Roll(0);                
            }
            Assert.AreEqual(0,terrestrialGame.Score());
        }

To test the constraints I need ti add frames in the test, but i can also say that the user should be exposed just the Roll method, so the method that get frames could become private.

That means eliminate the tests based on frames (if we don't want to test private methods).

The "bowling marziano" is based on just three frames of no more than tre rolls, and for any strike the bonus is the result of the last frame.

quick c# localization by java properties files and reflection

2010-03-16T23:34:00.006+01:00

A quick way to localize C# application is given by this example.
There is a trivial windows form application and a LabelManager project.

This is a sketch of how it works.
Visual Studio generates, for any form, two files. The second one is automatically filled with name ending by .designer.cs, that should not be edited, and that contains a InitializeComponent() function that assign values to widget according to visual development.

Assignment to Text element are in the form:

this.label1.Text = "This label is in english";

You know that the full path of the label1 element (by namespace.classname) is:

WindowsformsApplication1.SampleForm.label1.Text

So to localize this label in any language an international.properties file can contain the localized values espressing the fully qualified element property, preceded by a locale string, and followed by the desired assignment, as follows:

it.WindowsFormsApplication1.SampleForm.label1.Text=questo testo è in italiano
ru.WindowsFormsApplication1.SampleForm.label1.Text=Этот текст на русском языке

The App.config shoould contains the value (ru or it) for the current localization, in order to choose the version (italian or russian, in this case).
Note: the international.properties is encoded in utf-8 to manage special chars.

The call (not the definition) to InitializeComponent() must be followed by an UpdateUi(this) call that will change those properties according to locale and to the international.properties file, using a LabelUtils package.

Some script file can be useful to generate easily structure of the international.properties.
Until now I just used stuffs like this bash command:
for i in `find . | grep ".cs$"`; do echo $i; cat $i | egrep "Text ="; done;

(you need a bash shell interpreter)

This approach is original, and may require much more tests, and efficiency improvement, particularly about exceptions handling.

In few steps to use this approach :
create your forms and assign text values as usual by Visual Studio.
At any time (also when your application is completely done), detect all the properties assignable by strings, for example using some bashing.
Create an international.properties files assigning values to any properties by locale.
Assign locale in the App.config
Be sure that international.properties will be contained in the build directory, for example adding some copy directive in the AfterBuild target section of the vs build file.

Suggestions and contributions are welcome.

p.s. I mentioned about bash and the sample command:
for i in `find . | grep ".cs$"`; do echo $i; cat $i | egrep "Text ="; done;

the '`' may not be available in all the keyboards layout.
Change keyboard layout, or use the following command instead:
for i in $(find . | grep ".cs$"); do echo $i; cat $i | egrep "Text ="; done;

Ciao.
Tony

ocp bowling kata

2010-02-28T14:45:00.006+01:00

Started implementing in c# the bowling kata in the ocp way.

The ocp kata rule does not allow you to implement any new feature without having a base code respecting the open closed principle.

If it is not possibile, you have to refactor the base code at it.

In this way you are forced to improve the object oriented design.

Not so easy, and I think that this kata requires much more time than two or three pomodoros imo.

Ciao.

J. B. Rainsberger and Corey Haines discuss software business and development issues

2010-02-14T15:37:00.003+01:00

It was fun for me partecipating by chat to this discussion, making few questions:
http://www.ustream.tv/flash/video/4722190

string calculator kata

2010-01-04T19:33:00.004+01:00

I uploaded a new video about the stringCalculator kata:

stringcalculator kata from tonyx on Vimeo.

Other videos availables from other friends are:
http://www.vimeo.com/8206748
http://www.vimeo.com/8326880
http://www.vimeo.com/8506325
http://www.vimeo.com/8087998

Tests can show presence of bugs, and not their absence?

2010-01-01T23:02:00.016+01:00

Some interesting discussions are related to the famous statement:
"program testing can be used to show the presence of bugs, but never to show their absence!"
which is a variant of the fact that "absence of evidence is not evidence of the absence".

The discussions takes a simple example:
"the fact that there is no evidence that there is an elephant here in the room, is not an evidence that there is no elephant in the room".
We can drop the "not" because it is very unlikely that an elephant is here without being any evidence so:
"the fact that there is no evidence that there is an elephant here in the room, acually is an evidence that there is no elephant in the room!".

Seems reasonable, about being elephant in this room or not that "absence of evidence is also evidence of absence", but what if we talk about a fly:
"the fact that there is no evidence that there is a fly in this room is not an evidence that there is not a fly in this room".

The question is about "how much is close to zero the probability that I'm doing a mistake using the rule "absence of evidence implies evidence of absence"?
It's about the probability that using an abductive inference logical rule we get the wrong conclusion.

Probability of being in mistakes in terms of conditional probability:
p(there is an elephant|no evidence of elephant) is low (probability that there is an elephant in this room given that there is no evidence that an elephant is in this room)
p(there is a fly| no evidence of fly) is higher (probability that there is a fly in this room given that there is no evidence that a fly is here in this room)

If there are no evidence of being a fly here does not mean that we could really conclude reasonably that there is not a fly here.

Let's go back to the software testing question. The software testing analogy, is closer to the elephant or the fly example?
How much confident we are that "no evidence of bugs (i.e. tests passes) is evidence of no bugs"?

if p(bug | test passes) = 0 then "no evidence => evidence of not" would be a valid logical role.

But can be p(bug | test passes) =0?

That would mean: we are sure that we are not wrong when we interpret "all test passes" as "there is no bug".

From theoretical computer science the answer is that we could never be sure of it, i.e. the previous statement is theoretically wrong.
The "Rice theorem" states that cannot exist any automated procedure (testing program) that can recognize if another program (tested program) has some particular property (being bug free).

However it does mean not so much practically speaking, I mean, for example because of the following reasons:
- what do we mean by bug? From some point of view there does not exist a program bug free.
- we need p(bug | test passes) close to zero, not zero.
- Rice theorem talks about the impossibility that there exist a program that take in input any other program, like using it as a black box. Here is different: in tdd the program under test is not a black box. It's something that I know because it's what I'm writing in order to solve a problem that I know. Program grows without breaking existing tests, and that's a way to lower the probability of introducing bug by program changing.
- tests are a way to rewrite specifications in a language suitable for the coder and for the code under test. Test cannot be perfect as the specifications can't.

quality of non decreasing velocity

2009-12-26T19:11:00.001+01:00

About the "quality of non decreasing velocity" (Q_cv) concept. (http://peripateticaxiom.blogspot.com/2009_05_31_archive.html)

That model states that in any project the velocity can increase or decrease depending on the quality. Q_cv is a threshold such that, if your base code quality is higher, then your velocity will be increasing, and if lower, it will be decreasing.

You can figure out easily some empirical evidence of about being under the Q_cv: do start doing "quick and dirty" bad code, and because of the bad quality, in the long run, maintenance will be very difficult, slower and eventually much more dirty.

Mathematically: dV/dt ~ Q -Q_cv
This is a nice mathematical way to say that sacrifice the quality means being slower in the long run (perhaps being quicker in the short term).

I would say that fitting over the Q_cv threeshold means being in the area of sustainable quality.

Objections?
Pick up one of them, or add yours :)

1) "the models works (if it works) only in the long run, and it doesn't say what is, and how you can measure, the Q_cv, so how can you know if it worth the effort?"
2) "suppose I know Q_c, I also know I'm not able to fit in the over Q_cv/sustainable quality level [area], [thus I know it does not worth the effort].
3) "quality is perceived as aesthetic, and not pragmatic."
4) "in the short term, quality means being slower, particularly if you are not used to. Refactoring, unit test and mocking needs time and skills"
5) may be you can have empirical evidence that being the wort is the quality, the higher is the negative impact to the velocity, but it does not prove that there really exist this Q_cv threeshold, i.e. an area of sustainable quality.

Commenti.
Andrea (cui ora ho dato diritti di scruttura sul documento):
Io ho dei dubbi sul fatto che aumentare la qualità rallenti nel breve periodo.

Quello che costa è l'apprendimento di una
tecnologia o di una metodologia. Una volta appreso non costa più.
Quindi non è che ad esempio il TDD ti rallenta. Ti rallenta solo finché
non l'hai appreso.

Luca:
1 comment about the "in long run". if today the team do a quick and dirty fix on one code area and tomorrow the team have to add a feature in the same code area, that it will be in the short run. so when you measure the velocity of the team working on a specific code area, than the velocity decrease immediately. Users are interested in a steady flow of features so quality do matters. here is an interesting post on the topic To Fix Or Not To Fix?: Another Good Question
1 more comment about " how can you know if it worth the effort?": should measure the number of new bugs, the velocity of the team and compare the velocity of another team implementing a similar feature (i.e. adding a new payment methods to the web apps).

About Andrea comment I do agree, the bottleneck when striving for quality is skills and talent, not time: hire the right person, create a team where skilled/experienced dev are the majority and so can quickly teach to newcomers. One post in topic: Turning Skills into Money

A modular adapter

2009-12-08T17:50:00.006+01:00

This post is related to some code I wrote about creating a way to map different but similar objects, and is related to the adapter pattern.

This is not a "standard" way to use the adapter pattern, so if you are looking for the official adapter pattern, this post is not for you.

Suppose that two classes A and B do similar stuffs, in different way, and we are not able to decide which one we are going to use.
We want to find how they are similar, and how can we deal about deciding witch one we are going to really use at run time, in terms of how initialize them (in the A way or in the B way), and witch one will be the actual class used (real A o real B, provided that they will be viewed as a common interface).

We want to manage wrappers that maps one to another and create an abstraction layer that hides the real class, and manage in run time the concrete implementation.

Here is an example:
StringString manages and print strings, and is created passing the plain String objects:


public class StringString {
   private String string;
  
   public StringaString(String string) {
      this.string = string;
   }
   public void print() {
      System.out.println(string);
   }
}

The char version is called StringChar:

public class StringChar implements StringaGetter {
   private char[] chars;
   public StringaChar(char[] chars) {
      this.chars = chars;
   }
   public void print() {
      System.out.println(chars);
   }
}

They do really the same thing, but they are not created in the same way.

The wrapping code that allows to create the StringChar from String object is the conversion from String to char array string.toCharArra() and the wrapping code to initialize the StringChar having the charArray is new String(aCharArray).

What about creating of an abstraction layer between the how to create, and what it will be?
We will need to manage the wrappers between them, in order to be able, at run time to decide witch contract we are going to obey for the object creation/method, and what the concrete implementation will be.

We could choose any combination.

We are also going to change both the objects in order to implement a common interface so we will inspect them in a unique way established by an implemented interface, whatever is their actual class.

Here are our steps:

1) the common interface that both should implement is StringGetter:


public interface StringaGetter {
    public String getString();
}

2) both classes are slightly modified to to implement that interface from now:



public class StringaString implements StringGetter {
    private String string;
    
    // wee will see this later
    @convertible(contractClass = StringGetter.class)
    public StringaString(String string) {
      this.string = string;
    }
    public void print() {
      System.out.println(string);
    }
    
    public String getString() {
      return string;
    }
}

and:


public class StringaChar implements StringGetter {
    private char[] chars;

    @convertible(contractClass = StringGetter.class)
    public StringaChar(char[] chars) {
         this.chars = chars;
    }
    public void print() {
       System.out.println(chars);
    }


    public String getString() {
        return new String(chars);
    }

}

Both the classes are different in the way they are created and have some new behavior that obey to the contract defined by the StringGetter interface.
Moreover, we added a @convertible(contractClass = StringGetter.class) tag to the constructor.
Any other class that implements StringGetter interface and that add the same annotation to the constructor could be used for the same purposes.

The next step is to create an abstraction layer that will let us select any creational contracts, and any concrete implementation that means, the "apparent" implementation and the "actual" implementation.

This abstraction layer manages a map of wrappers.
A wrapper is an implementation of the following interface:


public interface Wrapper {
    Object[] wrap(Object[] object);
}

For example the StringToChar wrapper is the following:


public class StringToChar implements Wrapper{
    public Object[] wrap(Object[] object) {
        return new Object[]{((String)object[0]).toCharArray()};
    }
}

which converts a 1 size Object[] array containing a String to a one size Object[] array containing the corresponding charArray().

The opposite is the CharToString wrapper:


public class CharToString implements Wrapper {
    public Object[] wrap(Object[] object) {
        return new Object[]{new String((char[])object[0])};
    }
}

We need to inform our abstraction layer about using the two wrappers:


ConversionMap.getInstance().setMapper(
   StringString.class.getConstructor(new Class[]{String.class}),
   StringChar.class.getConstructor(new Class[]{char[].class}),
   StringGetter.class,
   new StringToChar());

The conversion from the parameters suitable for the former constructor to the latter that will be used in order to manage objects that implements the StringGetter.class interface is a StringToChar.

This is about the reverse direction:


ConversionMap.getInstance().setMapper(
   StringChar.class.getConstructor( new Class[]{char[].class}),
   StringString.class.getConstructor(new Class[]{String.class}),
   StringGetter.class,
   new CharToString());

At the end: we are going to put the "wrappable" constructors in a map, managed by the "modular factory", and giving them a name:


  MapOfConverterModularFactory mapConv = new MapOfConverterModularFactory(StringaGetter.class);
  mapConv.putImplementation("charString",
    StringaChar.class.getConstructor(new Class[]{char[].class}));
  mapConv.putImplementation(
    "StrinString",StringaString.class.getConstructor(new Class[]{String.class}));

And now we can choose to select witch implementation to use for the creational purposes and witch one the real implementation:


  mapConv.setCurrentImplementation("charString");
  mapConv.setRereferenceImplementation("StrinString");

Current is the "actual", and reference is the "apparent".

We were used to call StringString myString = new StringString("hello");
and now we will instead call:


StringGetter ob = (StringGetter)mapConv.getObject(
   new Object[]{"hello"})

And ob is built according to the StringString style, and of course, his current concrete class is StringChar:


assertEquals(ob.getClass(),StringaChar.class);

This is the opposite situation:


  mapConv.setReferenceImplementation("charString");
  mapConv.setCurrentImplementation("StrinString");

We were used to call StringString myString = new StringString("hello");
and now we will instead call:


StringGetter ob = (StringGetter)mapConv.getObject(
  new Object[]{new char[]{'h','e','l','l','o'}));

And ob is built according to the StringString style, and of course, his current concrete class is StringString:


assertEquals(ob.getClass(),StringString.class);

All the code will be on line asap.

Tony (8/12/2009)

agile and team dynamics learning values

2009-11-29T21:05:00.018+01:00

One of the first agile principle I learned is that we should introduce learning culture and remove blaming culture.
Blaming culture comes up easily. It is proved being viral and, in the long run, dangerous for the organization.

So no wonder that, particularly in critical and expensive fields such as the I.T., you can easily see the blaming game.

We need to introduce values that can step by step remove such unsustainable attitudes, and replace them with something better, technical ans social as well.

The chances to have success depends on knowing the following factors:
what is going on in terms of the "iceberg model of human behaviour",
what kind of mindset have the players: pre-conventional, conventional, or post-conventional,
do you have enough referent power?

The better you know that, and the better you can understand how much work is still needed to move to a learning/comunicative/healthy environment.

If you can exercise this "referent power", the simpler thing that you could suggest is: simple tools, simple communications, simple solutions, simple descriptions, simple documentation; a sprint backlog and a product backlog, or kanban, a daily stand up meeting, a shared wiki, discourage the use of emails for task related communications.

Is that all?
Not.
If you consider it enough, then it will probably will turn out in something like the "flaccid scrum".

I think that scrum tools are only the starting points. We have been able to write a backlog, and that means that we know that the P.O. knows what she wants, and, at least once, we probably know also how much can we do in a sprint, and we had the opportunity to discuss that between"pigs" and no "chikens".

This should be a good way to start a process that should allow us to learn by our feebacks.

The feedback could hopefully be, during a daily Scrum, something like the following: "I worked on this backlog item, I tested it (manually?), but I found that the code was not so clean so it toke much more time than we estimated, and probably I need more time working on it, and moreover I'm not sure if there is something else broken somewhere, so I need to work on it a little bit more on tests, and so on..."

So, we will realize this: the estimation have not be fulfilled because we have not been able to describe a clear definition of done, and we underestimated the side effect of implementing new features, because of preexisting unclean code without automated tests.
Those things are "wrong", but this kind of feedback is very good, as long as we can use this knowledge as an answer to learn, and consider that the questions contains what we need.

There is the possibility that such statement will not considered the key to find more answers, but just to play again the blaming game.
Consider for example this answer to the report of the developer: "yes but that means that you guys didn't do unit test, and you guys didn't write clean code..."
respect of the following: "yes and that means that the next time we should have much more consideration about internal quality as a unnegotiable part of the scope for any task, so unit testing and refactoring will be simply included in our activities."

Then there comes again the role of the coach (or scrum master) that is the one that makes the system move in the "learning way", instead of the chaotic way.

How? Difficult to answer, but one thing to know is that during difficult un-comfort situation, the learning can be much more powerful. Ben Fuchs:

"When we are exiting the comfort zone, it will be the time we least want to examine ourselves - and the seduction of self-righteous certainty of our positions will resist any questioning. But this is exactly the time to notice our reflex reactions, slow down and practice all the coaching and communications skills we have learned in seminars. If you can catch the process in the moment when it flares up, then the learning is much more powerful than after its over." (link)

29/11/2009

toward an open closed equals and subclassing strategy

2009-04-19T13:46:00.008+02:00

I have to say that this is a very buzz title.

I'm going to write about equals, subclassing, interchangeability between concrete representations... stuffs like that.

Object identity is difficult to define for me.

In some languages like java the .equals() as defined in the Object class indicates that the other object is the same object. It is stored the same memory location.
That implementation is the same as the '==' operator.

The equals is supposed to be overriden for any not mutable object so the meaning will be: object with the same state.
The java Set apis don't store duplicate objects, where an object is a duplicate of another if the former and the latter are equals (respect of the equals method implementation).

Some other examples can be less obvius:
think about classes that manages some rational numbers api we are wording on.

Will 1/2 equals to 2/4 for some rational numbers apis we are implementing?

And what if we talk about "fractions".
Some math guys (domain experts) would tell us that the two fracitions "1/2" and "2/4" are technically not equals, but the two "rational numbers" 1/2 and 2/4 are the same.

New Rational(1,2).equals(new Rational(2,4)) will be true, and new Fraction(1,2).equals(2,4) will be false.

So our choose depends of the name.

Does it make sense? mmm... yes, as long as we agree that we act under the umbrella of algebraic principles like"rational numbers are actually the equivalence classes of fractions, where the equivalence is defined as the fraction n/d is equivalent to n2/d2 if ..... [any definition that you like. One is: (n/d) * (d2/n2) = a/b where a and be are two equals relative number]"

Too heavy!

Yeah... right, but this is the art of computer programming: how much I'll go deep to the domain, to be consistent with some common sense future expectation, apply some design principles and so on...

Or we can avoid that: for example we are not going to write a unit test like
assertEquals(new Rational(1,2), new Rational(2,4));

Any time we display to the user a fraction, then we do GCD calculation and reduce the fraction, so the system will work perfectly as a black box.

Some other guy can get my code and say: for the I think that we deserve that kind of test, and if it does not work, then we have a problem. Even if there is no domain specification, customer requirement, about that. It's just common sense, comes up with least astonishing result, or because, for my math, algebraic background it is really strange that the domain is modelled without recognizing such obvius thing.

Thinking in this way is ok, and you can go much more deeper, also with much more implications, and the suggested solution can be reasonabile, but not obvius in the way it could be implemented.

Coexistence of different implementations of complex numbers: polar and rectangular.

There can even be different actual classes for them. Why not? Team A assumed rectangular representation, team B assumed polar representation and they developed their own implementations.

They were thinking about the "same" thing, but they did not implemented them in a compatibile way.

Now do we want make those classes working together? How?

Will we make them collapse in the same class? With two different constructor? One that takes the real and img parameter, and another one that takes the angle and magnitude?

Can be done, if the two constructor are not both considered as the same type (float, or double, for instance).

Another way to think that is like a pattern that abstracts the actual representation by a factory, and a way to define a metalevel description of equivalence.

The object will be seen only by an interface, (a "contract") with all the "observers" methods, and the equals can be implemented just cheking the fact that the other class implements the contract interface and that the interface defined observers produce all the same result.

Makes sense?
Can be: we are looking for something like

myObjectFactory.setImplementation("rectangular)
a = myObjectFactory.getObject(1,1);
myObjectFactory.setImplementation("polar")
b= myObjectFactory.getObject(sqrt(2),math.PI/4)
//a.equals(b) is true

and, moreover, we are free to use any implementation, and decide at run time to select any of them without changing the behavior of the program.

The next step is the ability to hide also the object creation diversity, disinguishing from the "apparent" implementation and the "actual" implementation:

myObjectFactory.setApparentImplementation("rectangular");
myObjectFactory.setRealImplementation("polar");
a = myObjectFactory.getObject(1,1);
// a.getClass() will return Polar
myObjectFactory.setRealImplementation("rectangular");
b= myObjectFactory.getObject(1,1,);

// a.getClass() will return rectangular
// a.equals(b) is true

We need to add at some metaclasses level the code conversion between different representations, and some guarantee about interchangeability, like with a lot of unit tests, even with random generated samples.

Let's go back to plain numbers. Another issue can be the "extensions":
we defined math about relative numbers, and we would like to extend those relative numbers to rationals.

They will be perfectly compatible. you can do 1+ 1/2 and get 3/2 as result.

We can see rationals as a class extension of naturals, and make the things work so 1 and 1/1 are considered equals.

Making that kind of thing works, can be not trivial, if you don't want surprises. There are two kind of equals implementations: instanceof and getClass().
The "instanceof" based implementation of equals does not respect the equals contract (being reflexive, transitive, simmetric), however the .getClass() based implementation returns false for objects that belongs to different classes.
So comparison with subclasses will be always false, then 1 and 1/1 will not be equals.
We can modify the rational number extendings the tests, including checking if the class belongs to the rational subclass.

That would be necessary for any extensions, and in that sense our equals implementation is not closed to extension.

There is an equals implementation tecnique, based on tree traversal, (google keywords: "secrect of equals") that is actually open to extensions and closed to modification.

Being always closed to modification can be impossible.
You will much more likely try to be closed to modification and open to extensions respect of the more likely future code evolutions (strategical clousure).
Fortunately for the equals there exist a closed (to subclassing) solution, so there is not strategy to think.
It is not so easy to understand, and any IDE generates the equals only according to the "instance of" or "getClass" alternatives.
Moreover, nowadays people don't like subclassing at all.

The mainstream approach is avoiding subclassing and prefer composition, so seems to me that nobody also cares about smart equals strategy open to extensions respect of subclassing.

Preview, development version of "Rosita"

2008-11-02T13:32:00.003+01:00

Rosita is an open source tool to practice your vocabulary of a language that you are learning.

It is based on:
1) an input text area where you write down the word you are going to memorize
2) an html/xml parsing engine that tries to looks up the translations of the words on google dictionary, completing the text are with tab separated format word + translation
3) a check box based exercise to play to memorize them.
4) an engine to lookup and visualize related sentences containing the words that you are practicing

The current set of terms can be saved and loaded in xml format (utf-8 encoded).

At a development phase, it supports just russian-english. In the next build I'll include other language pairs. Stay tuned.

A scenario of use of this tool can be the integtration with lingq (www.lingq.com) because the new learnig words (lingqs) can be easily exported by copy and paste into the rosita text area.

http://code.google.com/p/rosita/

Object substitutability with a random check to ensure equivalent behavior

2008-04-22T17:11:00.003+02:00

To read the article follow this link.

Cheers.

how to find what jar contain a particular class?

2008-02-18T19:21:00.004+01:00

Using the Unix bash shell:

if your current directory contains all the jar to scan, and the class you are looking for contains a substring like some.package.MyClass:


for i in `ls *.jar`;
do echo $i;
jar -tvf $i | grep some.package.MyClass;
done;

Your jars can be in different subdirectories, at any level, under the current directory. Then you can use:


for i in `find . -name | egrep ".*\.jar$"`;
do echo $i; jar -tvf $i | grep some.package.MyClass;
done;

The result is the list of all the jars, and if a particular jar contains a class that maatches the string you specified (some.package.MyClass), then the complete name of such classe is prompted after the jar.

Enjoy

No, you can't

2008-02-11T21:04:00.000+01:00

Obama Girl vs Giuliani Girl

2007-12-31T10:56:00.000+01:00

possibile use of java annotations to declare type mapping betwenn different representation of abstract types

2007-12-30T14:48:00.000+01:00

As we can find looking back at this textbook (Structure and Interpratations of Computer Programs) and particularly to this chapter, in order to have a sound data type hierarchy there must be a strong relation between different concrete implementation of an abstract data type.

The relation could simply be "the caller, that expects an abstract type, should not be aware of the particular actual type".

Who and how is responsible to make possible that the concrete type does not violates the caller expectations?

In the simple case of an immutable type, it is enough for us that there is a sound mapping attributes that is able to convert an instance of an actual type to the equivalent instance of the other actual type.

Where do we put this mapping?

For any constructor it will be declared how to convert his parameters, to the parameters needed by another constructor, in order to get an equivalent object, no matter if it is the same or of a different actual type.

The mapping is possible using the following mathematical relation between polar and rectangular reresentation of complex numbers:

The miniproject, with some unit tests, is versioned here.

The link between the caller and the actual implementation is provided by a factory, that is able to introspect the annotations to obtain the mapper that will be used to get a particular implementation.

Any new implementation should declare a mapping between different preexisting implementation.

We note that in this example we are using immutable objects.
Would we investigate also to mutable as well, we should be aware that it will not be just a matter of equivalence during object creation, but also after any repeated sequences of step that can change object state.

There is some work to address this issue as well.

Let's see some sketch of the underlining ideas:

Definition of complex:


public interface ComplexNumber {
 public double getReal();
 @observer public double getImg();
}

Here a Rectangular implementation:

public class RectangularComplexNumber implements ComplexNumber {
protected double real;
protected double img;

@instanceConverter(instanceConverterMap = CartesianToPolarMapper.class)
public RectangularComplexNumber(double real, double img) {
this.real=real;
this.img = img;
}

public double getReal() {
return real;
}

public double getImg() {
return img;
}

...


}

Polar representation has a different constructor, and two extra methods. It mantains also angle and magnitude, not just img and real:

public class ComplexNumberPolar implements ComplexNumber {
protected double magnitude;
protected Angle angle;

protected double real;
protected double img;

@instanceConverter (instanceConverterMap = PolarToCartesianMapper.class)
{
 this.magnitude = magnitude;
 this.angle = angle;

 this.real = magnitude*Math.cos(angle.getValue());
 this.img =  magnitude*Math.sin(angle.getValue());
}

public double getReal() {
 return real;
}

public double getImg() {
 return magnitude*Math.sin(angle.getValue());
}


public boolean equals(Object object)
{
...
}

public int hashCode()
{

}
public String toString()
{
}
}

We can see the two attributes associated to each constructor, respectively

@instanceConverter (instanceConverterMap = RectangularToPolarMapper.class)
@instanceConverter (instanceConverterMap = PolarToCartesianMapper.class)

This new attribute is defined in this way, and specify by default an identity mapper:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.CONSTRUCTOR)
public @interface instanceConverter {
Class instanceConverterMap() default IdentityToObject.class;
}

We specified different mappers

public class RectangularToPolarMapper implements WrapperToObject{
public Wrapper getWrapperForClassConstructorWithParameters(
 Class targetClass,
 Class targetParamsTypes[],
 Class[] originParamsTypes)
 {

 if (targetClass.equals(ComplexNumberPolar.class)) {
     return new CartesianToPolar();
 }
 throw new RuntimeException("wrapper not defined for the target class");
}
}

The returned "wrapper", is the following:

public class CartesianToPolar implements Wrapper {
public Object[] wrap(Object[] object) {
 return new Object[] {Math.sqrt((Math.pow((Double) object[0],2.0))+Math.pow((Double) object[1],2.0)),new Angle(Math.atan2((Double) object[1], (Double) object[0]))};
}
}

This is the one that is returned to make the inverse transformation:


public class PolarToCartesian implements Wrapper{
public Object[] wrap(Object[] object) {
 return new Object[]{(Double)object[0]*
Math.cos(((Angle)object[1]).getValue()),
(Double)object[0]*Math.sin(((Angle)object[1]).getValue())};
}
}

The guy that uses all that stuffs is the factory, that provide a link from abstraction type to actual type:


public class ComplexNumbersFactory {
....
public static ComplexNumber getComplexFromCartesianPar(double first ,double second)
{
if (RECTANGULAR.equals(implementation))
{
    return new ComplexNumberCartesian(first,second);
}

if (POLAR.equals(implementation))
{

    ComplexNumber converted = (ComplexNumber) Utilities.getInstanceOfThisActualGivenConstructorOfOther(
ComplexNumberPolar.class,ComplexNumberCartesian.class,
new Object[]{first,second},
new Class[]{double.class,double.class},
new Class[]{double.class,Angle.class});
    return converted;
}
throw new RuntimeException("unadmitted implementation mode "+implementation);
}

}

He fails if the lookup of the mappers fails, and it is a good thing, because it means that someone extended the concrete implementation without providing a way to relate the concrete implementation to the others.

Just for curiosity, the reflection based mapper lookup is done by the following code:

  public static Object getInstanceOfThisActualGivenConstructorOfOther(
Class targetClass,
Class originClass,
Object[] instanceOriginCompatible,
Class[] instanceOriginClasses,
Class[] instTargetClass)
{
 try {
     Constructor constructor = originClass.getConstructor(instanceOriginClasses);
     WrapperToObject wrapper = (WrapperToObject) constructor.getAnnotation(instanceConverter.class).instanceConverterMap().newInstance();
     Object[] convertedPars = ((wrapper.getWrapperForClassConstructorWithParameters(targetClass, instTargetClass,instanceOriginClasses).wrap(instanceOriginCompatible)));
     Constructor targetConstructor = targetClass.getConstructor(instTargetClass);
     Object convertedObject = targetConstructor.newInstance(convertedPars);
     return convertedObject;

 } catch (Exception e) {
     throw new RuntimeException(e);
 }
}

The factory shows a (real,img) way to construct the object, thus it has nothing to do if the concrete implementation is RECTANGULAR, otherwhise it lookups the mapper examining the constructor, and return the Polar concrete type.

At the end, we can show some junit test to verify that the things are ok:

   ComplexNumber first = new ComplexNumberCartesian(1.0,1.0);
// the actual of first is Rectangular
ComplexNumbersFactory.setImplementation(ComplexNumbersFactory.POLAR);

ComplexNumber second= ComplexNumbersFactory.getComplexFromCartesianPar(1.0,1.0);
// the actual of second is Polar.

assertEquals(((ComplexNumberPolar)second).getAngle(),new Angle(Math.PI/4));
assertEquals(((ComplexNumberPolar)second).getMagnitude(),Math.sqrt(2.0));
// no cast exeption

assertEquals(first,second);

Everything works as expected for the number 1+i.

Summary

A concrete type can be more efficient than another, but we need a save way to change concrete types.

Attribute are used to annotate to constructors how they are related to other constructor to guarantee cross types equivalences.

Something more than using only "extends" or "implements" keywords.

The due of plugging attributes to the constructor declaring the mapper is like saying: hi, if you are going to create a new implementation, you should also take care of how to make possible substitution between any other preexisting implementation with yours, and of course we expect that it will not affect any behavior expected from the other implementations.

(just a little note: the code is versioned, and it has also been refactored, soo can be a little bit different from how it has been shown in this post).

Regards, and Happy New Year!

T.

A Video of the New York Times, about Italy and Beppe Grillo

2007-12-16T18:26:00.000+01:00

http://www.nytimes.com/2007/12/13/world/europe/13italy.html?_r=1&oref=slogin

web 2.0 in 5 minutes

2007-12-09T21:55:00.000+01:00

Dancing with "mini" in Galway. December 2006

2007-12-09T11:12:00.000+01:00

Vilnius - Katedros aikštė

2007-12-08T14:16:00.001+01:00

One of the ordinary paving stones, about halfway between the cathedral and the bell tower, has been replaced with a not-so-ordinary paving stone. It’s the ‘miracle stone’, and it’s tucked under a piece of glass that has recently been replaced so that you can actually see through it (a miracle in itself round here). Embedded into the miracle stone, in coloured letters, is the Lithuanian word for miracle – STEBUKLAS. It’s written in a circle with a single S forming both the start and the end of the word. The stone marks the point where in 1989 two million hand-holding Balts joined together and formed a human chain that spanned the 650km between Vilnius and Tallinn. The tile has become a symbol of freedom and hope and, supposedly, can make your dreams come true. Stand on the tile, make a wish, and turn full-circle clockwise.

Odds, by Stanislaw Lem.

2007-11-24T17:28:00.000+01:00

You can find on line here an ironic essay of the famous science fiction polish writer, Stanislaw Lem (Solaris). It has been published in the book "Perfect Vacuum", a collection of book reviews of nonexistent works of literature.

"Lem is Harpo Marx and Franz Kafka and Isaac Asimov rolled up into one and down the white rabbit's hole" (Detroit News)

httpxmlfixture

2007-10-20T22:43:00.000+02:00

Recently I worked on a fixture for fitnesse, for xml xpath based acceptance test and test driven development for web applications.

It continues the approach introduced by this fixture that allows to check xpath respect to the content of a web page. Test can check if some nodes identified by xpath are present or not, if they contain some expected value, and how many nodes match the expression.

I added the following features:

- test pages that requires authenntication (basic o, in some cases, form)
- test pages not well formed, using jTidy as preprocessor
- manage cookies and so cokies based session
- manage post and get based parameters subscription.
- ability to generate test from statical pages.

This approach allows acceptance tests for web application only for server side plain web application (no javascript/ajax)

A sketch of the process of a "costumer test driven development" using this approach could be described as follows: you have a statical html, and you are going to modify some part of it to let it became dynamical (by some server side logic).

Creating the page is not viable by "test first".
We can just have for free a test that has success if applied to the page.
After we have the test ready, then we can modify, or reuse, it according to some user story that the page is involved to.
In this case we have a test first.

For example, suppose that we have the prototipe of the page, that contains a table.
The tabloe is the part that must be dynamical.

The customer says that "in the table there will be some data previously submitted by a form provided in another page".

To go a little bit deeper through this concept. The statical page could be something like the following:


<html>
<head/>
<body>
<table>
<tr>
<td>entry1</td>
</tr>
<tr>
<td>entry2</td>
</tr>
<tr>
<td>entry3</td>
</tr>
</table>
</body>
</html>

applying a stylesheet that generates the test from the page, you get the following test:

...
| Value | /html/body/table/tr/td | entry1 |
| Value | /html/body/table/tr[2]/td | entry2 |
| Value | /html/body/table/tr[3]/td | entry3 |

You can start coding creating a jsp that renders the page in the same way, where the data will be not hard coded. It will be retriven from a db.

The customer probabily doesn't care about db, or any persistency stuffs. He just asks that "the user will submit some data on that form, and the data will appear in the table".
(Thus such kind of test dos not involve business logic tier.)

A test based description of that story, can be as follows:

...
|newUrlPost|http://myserver/submitaction.jsp|
|NameValuePair|entryname|entryX|
|newUrlGet|http://myserver/visualize.jsp |
|AValue|/html/body/table/tr[*]/td | entryX |

that means somethig like "the submitaction.jsp you are going to implement, will expect a parameter named entryname. If the sumitted parameter is entryX, then, if you navigate to the page visualize.jsp, the entryX should be present in any part of the table"

This test describes what you will get, and you can start coding the submitaction.jsp and visualize.jsp until the tests doesn't fail.

To conclude, we can call this stuff an approach like:

. design the statical page,
. create test that matches if applied to the page,
. modify/reuse/rearrange the test according to a user story where the page is involved,
. code until the test doesn't fail

annotations to mutators and observers to show empirical evidence of substitutability

2007-10-17T10:28:00.000+02:00

I created a new project about experiment on object oriented notion of subclasing/substitutability based on annotations.

http://testlspjava5.googlecode.com/

You annotate mutator methods, and observer methods.
Mutators act to change object state, observer to inspect object state.
Instance generator is also defined, by annotations, to any mutator, to generate a (repeatable ) sequence of parameters to be applied to the methods.

A "random" computation on class is done involving the class, and is based on a repeatable sequence of instance generated to be applied to mutators methods.
It is repeated a second time, involving the subclass instead of the class. The empirical evidence of substitutability is the fact that at any step of the first and the second computation, there is equivalence, where equivalence is defined by same observable state, defined in terms of observer methods.

more about lsp and equals

2007-06-07T16:14:00.000+02:00

This post is related to a previous post, about relation between the "liskov substitution principle" and the technical methods choosen to implement equals.

Equals is a method derived from the Object class, that takes Object as parameter, and obviously can be overridden. If the method is not overridden, then the result is true if the two object are the same object. If the method is overridden, the comparison against any non null object returns true if the two object are to be considered equivalent for the domain of the program.
Only immutable objects should redefine equals.
A widely used technique to redefine equals is considering potentially equals only objects belonging to the same class (check is done using getClass()).

If the object belongs to subclasses? The fact that only object belonging to the same class, and not to subclasses, can be "equals" to an object, can be considered a violation of the Liksov substitution principle, so instead of getClass() the check can be done using instanceof.
However this can lead to an equals implementation that violates the equals contract.
There exists a workaround to this, explained here, that solves this issue, (without mentioning lsp).
There are few examples of code (and unit tests) implemented using this technique.

Angelika Langer, coauthor of the paper about the comparison strategy that I consider a solution, sent me a personal email telling me that this issue about "equals" has nothing to do with LSP: "Talking about LSP in conjunction with the implementation technique chosen for "equals" is a red herring".
In her opinion the big issue is just that Java forces you to redefine equals because of the way it works in conjunction with collections, and so you are forced to use different semantics comparisons using the same method name.
She told me that the issue is basically a java design flaw, and anything about LSP.
Moreover she invited me to take a look, for example, "at the containers in
the C++ standard library. They do not require any hard-wired function
names for equals or compareTo thereby allowing to avoid the problem of
different semantics under the umbrella of the same function name"

I would agree on that, however, I just think that LSP *has* to do with equals implementation because:
the principle has to do with object behavior and object behavior has to do with it's methods, including "equals".
This is my very humble opinion.

A way to define lsp is:
"function that uses pointers or references to base classes must be able to use objects of derived classes without knowing it" (http://www.objectmentor.com/resources/articles/lsp.pdf).

In any non final classes, equals method, if implemented via getClass(), always return false when applied to subclasses (unless it "knows" such subclasses i.e. coded so that the getClass() comparison is made also for all known subclasses of the class. This is a violation of lsp in those terms : "[if] a function does not conform to the LSP, then that function uses a pointer or reference to a base class, but must know about all the derivatives of that base class.")

If the comparison is made using instanceof, then class objects can be equal to subclass objects (without making the equals method having to know them, but there is the risk that the equals is not transitive, simmetric, and so violates the equals contract.
For examples see: http://angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals.html)

For other references about the "instanceof" vs "getClass()" argument in implementing equals see also:
http://www.artima.com/intv/bloch17.html (curiusly Joshua Bloch is for "instanceof", to preserve the possibility to make comparison to subclass objects, and in the same time in his book the example is based on _final_ classes, that cannot be subclassed).

About examples that show when class/subclass equality has sense:

a Rectangle with only positive values of X and Y is subclassed with a Rectangle that can be instantiated with negative X and Y values as well.

(It is a subclass that weakens the "precondition" and thus, incidentally, is compliant by the design by contract specifications.)

If rectangle redefines equals by getClass() then RectangleWithNegatives(1,1) is not equals to RectangleImpl(1,1).

In this case instanceof solves the problem (and is compliant with equals contract).
getClass does not.

There are cases in witch subclasses extend other attributes (new dimension, color and so on...)
and in such cases instanceof does not respect equals contract (see, again http://angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals.html)

You can simply avoid the problem considering rectangle with color not subclass of rectangle and rather a composition of rectangle and color.

However, if you do subclass it, then:

if

you want that your equals implementation will be able to return true if applied to object of the class and to object of a derived class as well.

and

in your domain there is an equivalence relation between (a subset of) subclass objects and class object and you look for an implementation of equals that fulfills this equivalence and equals contract

and

you want an "equals" solution "closed" against subclasses (i.e. does not need to know subclasses),

then

the aproach of equals shown in http://www.angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals-2.html and implemented in my examples is appropriate.

Possible critics:
a - "the lsp does not hold in java at all".
b - "avoid subclassing: it is dangerous. Use different solutions, like composition"
c - easy to talk about toy examples. And what about real problems?

a) yes. It is easy to say that "lsp does not hold in java". Lsp states that S is subtype of T if you can do some class/subclass substitution without changing the behaviour of any program.

"If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T."

It's easy to show programs that changes their behaviour making substitution.

example, all the programs that contain the statement: if myObject.getClass().equals(T.class).

It is defined in terms of T, and if it is applied to any different class, including subclass, returns always false, and if applied to any object of T returns true.
So for all object of any class different from T, there is no possibility to substitute such object with object of T, and thus in Java cannot exist any class that is subclass of T (!).
I.e. no class in java can be subclassed without violating LSP.

See also (http://alblue.blogspot.com/2004/07/java-liskov-substution-principle-does.html)

The interpretation is ok. Then: avoid subclassing.

Another approach is to weaken the lsp definition in the following way:

given that in our language "lsp does not hold strictly" then it is our option to implement our classes and subclasses in a way that if we use them in a clean object oriented approach, then lsp holds.
Using run time type information is not what we mean by clean object oriented approach.

So we can apply the statement in this way: "if you subclass, do it in a way that lsp holds if your object are used in a pure oo".

b) "avoid subclass". Avoid subclass when we know that is so dangerous.
Why is it dangerous? Because we cannot predict what happens during subclassing. Something unexpected happens because we do not comply with some principles like lsp? (Design by contract)? Sounds like "The chiken and the egg".
So: use object oriented, and follow design principles, and apply the same unit tests related of any class, to subclasses as well, then you will not be afraid of subclass.

c) what about real examples? I'm working on it. Any hint is welcome.

google acquires doubleclick

2007-04-14T12:26:00.000+02:00

A very big step:
http://www.businessweek.com/technology/content/apr2007/tc20070414_675511.htm?chan=top+news_top+news+index_businessweek+exclusives

Now any banner used by doubleclick can show "personalized" content per user profiled by click through analysis that doubleclick potencially already own *and* user analysis stored by google ads, google search, text analysis on the gmail account and so on...

tree traversal "equals" implementation

2007-03-07T12:03:00.000+01:00

I tested the "tree traversal" approach to the implementation of equals.

It is not so straighforward to understand, but you don't need to do it to be sure it works. I just wrote unit tests that checks that simmetry, transitivity contract is respected combining class/subclasses and differnet branches of a same class herarchy. It is enough to prove thet it works.

Using this approach, if you extend any class A to class B, and you redefine the "equals" method for A, then for two object a1, and a2, belonging to A, initialized in the same way, a1.equals(a2) is true, and a1.equals(b1) is true for any b belonging to B initialized int the same way of a1 (and eventual extra fields that are in b and not in a, must have default values).

tree traversal for mixed type comparison

2007-02-16T16:21:00.000+01:00

In the follwing link something better about "mixed type" implementation of equals. I'll apply it to the examples about my previus post.
http://www.angelikalanger.com/Conferences/Slides/JavaEquals-ACCU-2002.pdf

Liskov Substitution Principle in Java

2007-01-09T00:07:00.000+01:00

I'm working on some examples that show what is, as I can understand, the meaning of the Liskov Substitution Principle, and how you can deal with it in Java.

The home of the project is http://code.google.com/p/sampleliskov/

A lot of issues are pointed out, particularly about the implementation of equals in a way that respects the principle and the equals contract (transitivity, simmetry, reflexivity) as well.

Another point is a sort of randomized test that shows statistical evidence that two objects are substituble.

You can find on the net a lot of opinions and example of code, that advocates implementation of equals by getClass, or by instanceof.

You can put on google keywords like "some objects are not equals than other" or "equals liskov substitution principle Bloch" to find those opinions.

Essentially: the guys that prefer to implement equals by getClass say that using instanceof violates the equals contract (simmetry and so on...), and the guys that advoacate instanceof says that implementing it with getClass doesn't respect the Liskov Substitution Principle.

The second is true, but I think that the first is not necessarily true, and it's I'm trying to investigate.

Issues about intanceof may happen when you compare a class with its subclass: there can be no transitivity, or, after fixing this, no simmetry.

After this experience I'm confident that it is possible to address this issue in a simple way: when you compare a class with any class that is recognized as a your subclass then you delegate to the subclass the equality check.

This check is also "open" to extentions and so it does not violate another related principle that is called "open closed".

Other parts of the code are related to other issues about lsp and some way to detect lsp violation without using any "design by contract" extension framework.

A simple approach is: use Junit and rewrite the same tests you wrote for the class, for the subclass as well, and if those tests does not succed, then the principle is violated.

Another triky approach I experimented suggests a sort of "randomized" test: generate a random sequance of state for the object of the class, repeat it for the object of the subclass and then check their "equality".

Tonino

P.s.: I want to make clearer something about this "equals" concept, because you can argue, correctly, that "equals" is not the correct term. It rather should be called "equivalent state" or "similar".
In fact two mutable objects should not implement equals as "same state", but as "same object". (from Barbara liskov - Program development in java, pag 94).
I can use, for mutable object, another method, like "similar", according to Liskov .
I'd have to change the code a little bit in order to be more compliant with object orientation.
I'll write a "revised version" of this post.

However: it does not change the mainstream ideas I focused that are:
- the implementation of equals in a way that allows mixed type comparison between type and subtypes, with "open closed principle" compliancy
- the "randomized" test that shows statistical evidence that two object are substituble.