Computer Science Lover

2011-11-30T11:08:00.001+01:00

Nel settembre 2009 scrissi questo blog post: i falsi miti del Customer On Site

Son passati 2 anni e sono della stessa idea. Ho cambiato progetti, clienti, sedi, ma c'è sempre una costante: l'incapacità organizzativa che si manifesta in questi fenomeni:

essendo lo sviluppatore (o il cliente) 'in zona' non ci sono momenti dedicati per il planning, o la raccolta di specifica, o la dimostrazione di ciò che si vuole o che si sta realizzando. Sia lo sviluppatore che il cliente sono implicitamente sempre disturbabili. Quindi spesso vengono disturbati, e di conseguenza portano avanti tante attività, tante parentesi aperte, senza chiuderne alcuna per parecchio tempo.

Last in first out: è difficile delegare e incasellare le attività in qualcosa che si può fare prima o dopo. L'ultima mail o l'ultima telefonata sono sempre più importanti di qualsiasi attività in corso. Tale incapacità di prioritizzare le attività porta a ritardare l'obiettivo e a non portare mai avanti attività di media o bassa priorità, che sono comunque importanti.

Sul concetto di bassa priorità rammento che in un progetto recente un team ha delegato ad un solo collega la scrittura e manutenzione degli script di deploy dell'applicazione. Quando qualcun altro doveva metterci mano si sentiva a disagio, non avendo mai affiancato lo sviluppatore originario. Quegli script erano frutto di venerazione e timore, perchè a lungo sono andati senza bisogno di conoscerli. A fronte di un problema l'unica speranza era di 'riprovare' e sperare di non aver bisogno di aprirli in lettura :) La manutenzione degli script e in generale il passaggio di consegna sono sempre state considerate attività di bassa priorità da parte del team, era tutto sacrificabile rispetto all'ultima richiesta del cliente di dare un colpo di vernice al front web.

Insomma le soluzioni sono sempre quelle:
1) che tu sia dal cliente o no, accordati per dei momenti dedicati dove svolgere le varie attività di sviluppo
2) dai importanza alle attività in alta priorità ma lasciati un buffer temporale costante dove portare avanti attività di media e bassa priorità.

Feedback?

[Script] automatically crontab update

2011-08-16T14:10:00.006+02:00

Sometimes you need to update a crontab configuration in multiple enviroments (staging, production...).

If you have properly configured ssh, you can use this shell function:


function addToCrontabIfNotAlreadyPresent() {

HOST=$1



ssh -o "BatchMode yes" $USER@$HOST  << EOF



    crontab_line="5 0 * * * cd ~/yourproject/ && ./script/run.sh >/dev/null 2>&1-" 

    alreadyInCrontab="\$(crontab -l | grep "\$crontab_line" )"

    

    if test "\$alreadyInCrontab" == ""; then

       crontab -l > /tmp/updating_crontab.tmp

       echo "\$crontab_line" >> /tmp/updating_crontab.tmp

       crontab /tmp/updating_crontab.tmp

       rm /tmp/updating_crontab.tmp

       

       echo "Crontab updated"; 

    else 

       echo "Crontab ok"; 

    fi

EOF

}



USER='your_user'

addToCrontabIfNotAlreadyPresent "10.10.10.10"

[Agile] meglio un mal di testa ogni giorno o un cancro una volta nella vita?

2011-06-24T13:55:00.004+02:00

I team agili, la trasparenza e la percezione della velocità.

Penso che i team agili a volte si tirano la zappa sui piedi.
Il fatto che si esplicita un piano di iterazione (consegneremo queste funzionalità entro una settimana da oggi), che si fa una review del piano (su questa funzionalità siamo arrivati in ritardo) e che spesso si esegue una dimostrazione e verifica col cliente di quanto consegnato è un fatto virtuoso.

E' un fatto che tendenzialmente le stime sono piu basse di quanto di solito ci vuole a completare davvero una funzionalità (lo dico per varie ragioni che potrei argomentare, raccolta numeri e confronto con vari team) quindi tendenzialmente un progetto avrà tanti piccoli ritardi, comunicati costantemente durante la pianificazione lavori.

Il cliente sentirà spesso ripetere che ci sono stati tanti piccoli ritardi e la sua tendenza sarà di percepire una lentezza del team 'agile' che ha virtuosamente collezionato e comunicato queste informazioni.

Altri team non agili non danno grande visibilità sui lavori, vivono in pace e lasciano vivere in pace il cliente fino ai dintorni della famosa 'data di consegna'; lì tutti si aspettano di rodersi il fegato perchè quel giorno diventa per forza di cose un momento di confronto tra aspettative e risultati.

E' vero però che il cliente sente di un grosso ritardo, somma di tanti piccoli, dopo un bel po' di tempo, e fino ad allora è vissuto bene.

Insomma, il dubbio è: l'eccesso di trasparenza aumenta la percezione che i team agili siano più 'lenti' rispetto ad un team non agile?

In altre parole, meglio un mal di testa ogni giorno o un cancro una volta nella vita?

[Agile] da noi non si può fare

2011-05-05T17:13:00.003+02:00

Quando mi capita di confrontarmi con persone interessate alla tematica di introduzione di un metodo di lavoro sento spesso delle obiezioni abbastanza comuni.

E mi pare che negli anni le maggiori problematiche siano all'incirca le stesse.
Provo a riassumerle con degli slogan e una classifica. Al primo posto :

1) "Da noi non si può fare"

Spesso si pensa che la propria realtà lavorativa sia assolutamente straordinaria e unica per quanto riguarda colleghi, rapporti con il management, rapporti con il cliente. Io penso che sia abbastanza simile da tutte le parti, e si compone così:

rapporto con i colleghi: di media buono con quelli dello stesso team. Probabilmente il fatto di lavorarci tutti i giorni incentiva l'impegno a creare relazioni piacevoli. Quello che noto è che quando ci sono team diversi si tende a parlare delle persone degli altri team 'disumanizzandoli', banalmente smettendo di chiamare per nome e cognome e sostituendo con un sostantivo generico. Ad esempio frasi del tipo: "Quando si lavora con gli *(indiani|cinesi|spagnoli|americani)* è sempre un disastro" "il team di *(analisi|test|dba|plm)* ci mette il bastone fra le ruote". E allora in questo senso vedo bene tutte quelle pratiche che portano a ripristinare i nomi e i cognomi, al fine di avere una comunicazione umana.

rapporto con il management o con i commerciali: tendenzialmente ogni sviluppatore pensa di essere migliore del proprio manager o del proprio commerciale nei loro rispettivi lavori. Mi sbaglio? Mi chiedo quindi se è anche vero che ogni commerciale o manager pensa di essere migliore dei propri sviluppatori per quanto riguarda la codifica. Se così fosse sarebbe buffo! Ma in effetti a volte *forse* manager e commerciali ci azzeccano, quando ci chiedono delle funzionalità davvero banali tipo 'sposta questo link da destra a sinistra' e la cosa genera giorni di lavoro.

rapporti con il cliente. E' mia convinzione che un buon cliente gioca sempre il ruolo dell'insoddisfatto ma continua a mantenerti come fornitore. Ovviamente questo non vuol dire si debba dormire sugli allora o lodarsi per sempre. Ma questo porta allo slogan numero due:

2) "Siamo lenti" oppure "il team XXX non è abbastanza produttivo"

Posto che non è possibile definire chiaramente la produttività, e qualsiasi metrica che viene _imposta_ per misurare la produttività verrà di certo raggirata, la risposta deve andare nella direzione della chiarezza. Non si è produttivi rispetto al passato? O non si è produttivi rispetto ad un altro team? La ricerca di una metrica è una scusa per cercare di sviscerare e oggettivare la percezione di lentezza di un team.

3) "Mi sembra che ci sia poca documentazione"
Sì, in certi ambienti si ama la carta. Ammetto di essere uno di quei sviluppatori che di base reputano la documentazione inutile perchè non porta valore. Ma so che in certi casi mi sbaglio. Quel che noto in verità è che quando lavoro in un team XP scrivo molta piu documentazione di quando lavoro da solo. Esempi:

documento tutti gli script
manutengo il file di istruzioni per il setup del progetto
scrivo un journal delle attività ogni fine giornata
scrivo un iteration report da consegnare al cliente ogni fine iterazione
scrivo un riassunto di ogni meeting che si effettua

Alla base di questa critica che viene fatta all'XP o Scrum o quel che sia pongo solo un principio: che non scrivo per principio ciò che non viene letto. Se scrivo qualcosa è perchè qualcuno davvero la legge e trova valore in quel che scrivo.

4) "Non posso migliorare il codice perchè non mi viene allocato del tempo per farlo"
E' virtuoso coinvolgere il cliente nel processo di sviluppo del suo prodotto, ma non è furbo farlo ad ogni livello, sopratutto scendendo troppo nel tecnico. L'importante è mantenere i RUOLI. eXtreme Programming e Scrum li identificano con grande precisione, cosa può o non può fare un cliente e uno sviluppatore. Non ha senso chiedere a un cliente se dopo che hai risolto un baco puoi scrivere un test per garantire che non accada più: lo fai e basta. Il cliente non ha alcun diritto di entrare in merito alla gestione di task tecnici.
Immedesimandomi in un cliente, non farei fare allo sviluppatore niente di cio che non capisco, tranne poi lamentarmi degli effetti.

Nella stessa direzione va la maggior critica che viene posta al "pair programming":

5) "Non possiamo fare pair programming perchè il management non vuole due persone lavorino sulla stessa cosa"

Ok. Mettiamola così, se la situazione lavorativa è buona e il management non si lamenta, va bene non fare pair programming. Altrimenti è giusto sperimentare, coinvolgere, ma come dicevo prima è fondamentale distinguere cosa si può fare in un certo ruolo.
Se il management forza i tentativi di miglioramento del team, ed ha il diritto (diritto, non il potere) di farlo, va bene purchè poi si assume le responsabilità della scelta, prendendo quindi su di sè eventuali critiche sulla 'produttività' del team. Patti chiari, amicizia lunga. Però per ragionare in questo modo ci vuole coraggio! Dimostriamo che davvero c'è miglioramento nell'applicazione di una tecnica!
L'invito è di provare, di valutare dopo un certo periodo di tempo e non scendere a compromessi se non dopo averla imparata con una certa disinvoltura.

In bocca al lupo!

[Ruby] A Quick Ruby Kata Solution

2011-04-05T11:50:00.003+02:00

First solution of the kata described here:

http://railsrx.com/2010/09/27/a-quick-ruby-kata/



PAIRS   = [ [1,1], [2,2], [3,3], [4,4], [5,5] ]
SINGLES = [ 1, 2, 3, 4, 5, 6, 7, 8, 9 ]

def single_from_pair(pair)
  [pair[0]]
end

def sum(pair)
  pair[0] + pair[1]
end

result = []

PAIRS.each do |pair|
  (SINGLES - single_from_pair(pair)).each do |y|
   (SINGLES - single_from_pair(pair)).each do |k|

      z = 15 - sum(pair) - y - k 
      if z > 0 && z != single_from_pair(pair).first
        candidate = [pair, y, k, z].flatten.sort
        result << candidate unless result.include?(candidate)
      end
    end
  end
end

[Rails] Html to plain text

2011-03-22T14:34:00.004+01:00

I need to extract some text from a model in order to publish it in a CSV file. My problem was that one field's content is in pure html, like:


& quot; name & quot;=& gt;
[& quot;TommasoTorti& quot;, & quot;Tommaso& quot;]

; but in my csv file i need the text in a plain format.
One way is to unescape the html in the model:


def to_csv
[... , CGI.unescapeHTML(self.field) ].join("\t")
end

and insert the 'raw' command inside the view:


<%= raw my_model.to_csv %>

(The controller's code:


 @models = MyModel.all
 response.headers["Content-Type"]         = "text/csv; charset=UTF-8; header=present"
 response.headers["Content-Disposition"] = "attachment; filename=my_models.csv"
 render :layout => false

)

[Performance] memory leak analysis with JProfiler for a java webapp

2011-03-09T12:50:00.002+01:00

I wrote a first draft that explains how to use JProfiler to analyze possible memory leaks in a classical Java application.
Following the article: https://github.com/tortitommaso/PerformanceAnalysis/raw/master/MemoryLeak.pdf
You can follow this tutorial to gain a method to conduct such an analysis. Good luck.

[Rails] Test di convenzioni interne

2011-03-07T17:17:00.002+01:00

Una tipologia di test assai utile sono i test di integrità delle convenzioni, che eseguono un check di sanità su una certa convenzione interna che il team si è dato per lo sviluppo/ manutenzione di una funzionalità.

Faccio un esempio concreto.

Nell'applicazione RAILS ereditata su cui stiamo lavorando (io e Ivan Lombardi Borgia) abbiamo alcuni modelli sempre chiamati sub_form che l'utente ADMIN può osservare e scaricare in versione CSV, con tante colonne quante i campi del modello e i valori correnti.

L'implementazione concreta prevede il render di alcuni partial ( '_header.xls.builder' , '_row.xls.builder' e '_empty.xls.builder' ) riferiti al modello sotto esame. Tali file sono presenti all'interno di ogni directory del tipo sub_form_something e ogni view ha sempre un solo campo di riferimento @sub_form.

La regola è:
"Ricordati che se aggiungi o togli campi dal modello di riferimento devi aggiornare i partial dell'export"

Ovviamente nel tempo non ci siamo ricordati ;-) quindi abbiamo optato per automatizzare con un test di configurazione questa regola:


it "should export all model's field" do
  assert_fields_in_export(Factory.create(:first_sub_form), "first_sub_form_dir", do_not_include = ["countries", "leader"])
  assert_fields_in_export(Factory.create(:second_sub_form), "second_sub_form_dir")
end

e l'implementazione della assert custom:


def assert_fields_in_export(sub_form, sub_form_dir, do_not_include = [])
    view = ActionView::Base.new(ActionController::Base.view_paths, {})

    class << sub_form =" sub_form" row_output =" view.render(:file"> "#{RAILS_ROOT}/app/views/account/#{sub_form_dir}/#{file_name}")

    assert_equal sub_form.class.columns.length - (["id", "created_at", "updated_at"] + do_not_include).length , row_output.scan(//).length
    }

end

Se ad esempio alla first_sub_form aggiungiamo un campo il test fallisce indicando: mi aspetto 13 campi ma ne vedo solo 12. Quindi potremo o escludere il campo dall'elenco da controllare oppure aggiornare i file. Il test non è ricco di dettagli, serve solo come remainder di una convenzione che ci siamo dimenticati di rispettare.

[Poesia] Orizzonti di Sabino De Bari

2011-02-10T19:47:00.001+01:00

Orizzonti

Ho attraversato mondi incomprensibili,
di cui non sapevo il nome, nelle mie molte vite riunite in uno sguardo solo,
quello di chi non conosce orizzonti.
Cercavo riparo dal vento che sferza, dalla pioggia che allaga, dal sole che acceca, dalle parole che feriscono, dagli sguardi che accusano e dagli abbracci che soffocano.
Riparo dalla mia immagine, coperta di ombre, uomo povero di sorrisi, con un cuore che non capisce.

Ma poi una musica è giunta a me.
Un canto di voci che senza capire io ho capito, riconosciuto e accolto, e ritrovato.
E ho saputo.

Che ho amato tutti gli amori possibili, fuorchè quello per me stesso.
Che non è il mondo che cambia ma il cuore che si eleva, e che trasforma.

Così ho camminato, come per la prima volta, e ho scoperto un vento che può parlare, e una pioggia che può nutrire, sole che fa strada e parole che guariscono; sguardi che regalano e abbracci che proteggono.

E la mia immagine, nuda e indifesa, e finalmente autentica, e in cerca di sorrisi.
E un cuore collettivo, che batte insieme al mio.

Così ho capito.
Che non esistono domande quando la risposta è felicità.
E ho aperto gli occhi,
vinto dalla pace,
circondato da orizzonti.

[JQuery] highlight event detail with jquery

2011-01-14T11:11:00.005+01:00

My html page has multiple events inside a div identified by a prefix and the event's id.

Look at this example:

< id="event_1">...< /div >
< id="event_2">...< /div >...

I want to highlight the selected div when the user click on the link inside it and, in the meantime, deselect all the others divs.
My css:
.time_line_event_highlighted {
background-color:yellow;
}

Here is the jquery snippet:

$("#" + divId).click(function(){ // when a user click on a link inside a div...
$('div[id^=event]').removeClass("time_line_event_highlighted");
$("#event" + id).addClass("time_line_event_highlighted")
...
});

[Ricetta] mais e tonno

2010-12-22T14:08:00.002+01:00

Aprire una scatola di mais e versare in un piatto
Aprire una scatola di tonno, preferibilmente in olio di oliva (non extravergine), eventualmente scaldare per 1 minuto o 2

Mescolare con tanto amore nel piatto e servire con crakers e acqua gassata.

[Rails] how to tail log from multiple servers

2010-10-20T15:19:00.002+02:00

A different approach from the one described here: http://serverfault.com/questions/112457/tail-multiple-remote-files
is to use a capistrano task like (in my deploy.rb ) ,

task :tail_logs, :roles => :your_server_tag do

cap production deploy:tail_logs

run "tail -f #{current_path}/log/production.log" do |channel, stream, data|

puts # for an extra line break before the host name

puts "#{channel[:host]}: #{data}"

break if stream == :err

end

[Rails] from html to pdf

2010-06-18T11:39:00.001+02:00

I'm trying to use the nice library PDFKit, used for generate Pdf given an html in a rails application.

An interesting strategy for retrieving html generated by rails in order to put it directly in your pdf is shown in the following example:

def export_pdf

html = render :layout => false

kit = PDFKit.new(html)

kit.stylesheets << RAILS_ROOT + '/public/stylesheets/your_css.css'

send_data(kit.to_pdf, :filename => "your_pdf_name.pdf", :type => 'application/pdf')

end

[Code] Abilitazione e disabilitazione funzionalità a run time - senza GIT

2010-06-17T12:52:00.002+02:00

Una esigenza comune a pressochè tutti i progetti è quella di abilitare o disabilitare funzionalità con facilità.
Un esempio sono le ultime funzionalità sviluppate, non ancora testate nell'ambiente di staging, che non devono finire in produzione.
Ecco quindi che GIT o sistemi analoghi di controllo versione tentano di risolvere questo problema: una branch per ogni funzionalità e quando vuoi comporre il tuo pacchetto di installazione selezioni le branch a piacimento. Eppure mi pare una soluzione di bassissimo livello, che lavora con i file e non per alto livello tipo le funzionalità.

Concettualmente mi piacerebbe una dashboard di installazione, dove sono elencate con delle checkbox tutte le funzionalità dell'applicazione. L'applicazione sta su un solo ramo, senza alcuna branch.
L'amministratore può quindi disabilitare o abilitare funzionalità a run time, senza bisogno di riavvio. Questo è un sistema che mi piacerebbe !

[Rails] paginate with will_paginate plugin

2010-05-12T12:42:00.005+02:00

I'm using the will_paginate plugin for rails.
Unluckily, my query aren't in the form of:

MyModel.find(:all..)

in this case the main change is simply replacing 'find' with 'paginate' as described in the site.
I have a collection of MyModel object retrieved in a lot of different ways.
My solution, based on what i can see here , is calling a method (outside the controller class):


def self.paginate(my_collection, params)
current_page =
if params[:page].nil?
 1
else
 params[:page].to_i
end
per_page = 10
page_results = WillPaginate::Collection.create(current_page, per_page, my_collection.size) do |pager|
  start = (current_page-1)*per_page
  pager.replace(my_collection[start, per_page])
end
page_results
end

and, in the view:


<%= will_paginate @page_results, :params => params %>

[Xp] la domanda sbagliata

2010-04-29T10:32:00.002+02:00

E' successo ancora.
La domanda sbagliata che uno sviluppatore fa al suo project manager: "ci sono priorità particolari tra queste funzionalità?"

La risposta è: "no, parti pure da dove vuoi, tanto le devi fare tutte".

Non è professionalmente corretto supporre che non ci siano priorità, la domanda giusta da porre è: "QUALI sono le priorità, qual è la prima funzionalità su cui inizio a lavorare?"

[Book] Agile coaching

2010-01-18T23:40:00.004+01:00

I'm reading "Agile Coaching" ; until chapter 4 it's full of trivial suggestions. It looks like a priest when he recommends you to become more good for the near future.

Now i find some interesting advice. Noone of them is new, but it's always useful remember them.

Not Too Easy, Not Too Hard
The secret to great teams is they need reachable but challenging goals.
Everyone needs to be sufficiently challenged, neither bored nor anxious.
This is the optimum work zone where people enjoy it the most.
If work is too easy, developers will get bored and demotivated.

... and the solution...

Time for Innovation We’ve met developers on Agile projects who were burned out by working on a continuous stream of user stories. If they don’t get time to explore new technology or experiment with innovative product ideas, teams become demotivated. Make time in iteration plans for them to explore new ideas.

(like the Gold Card practice)

And always remember to...

Celebrate Success!!!
Find ways to celebrate the success of every release. Having a team
lunch or drinks celebrates success and increases team bonding.

[Life] customer care

2010-01-07T18:15:00.008+01:00

I have an example of an ugly customer care service.
I'm trying to buy some books from bol.it . I don't know the exact reason but bol.it cannot withdrew money from my bank. I asked for some explainations and the answer was (in italian):

they store my credit card number
i cannot modify my credit card number
i need to make another order in order to modify my credit card number
i need to call them at a payment phone number ...
...to comunicate by voice another credit card number

i think that if you really want my money you need to cherish me.

[Code] java quiz

2010-01-05T17:21:00.004+01:00

First
Look at the following test code:


@Test
public void quiz1() throws Exception {
        assertEquals(9, 01 + 08);
}

The result is:
1) green bar
2) red bar
3) doesn't compile
4) it throws an exception

Second


@Test
public void quiz2() throws Exception {
 Integer x = 1288;
 Integer y = 1288;
 assertTrue(x == y);
 int z = 1288;
 assertTrue(x == z);
}

1) first assert red, second green
2) green, red
3) green, green
4) red, red
5) doesn't compile
6) it throws an exception

[Test] How to sort junit tests by execution time

2009-12-29T14:27:00.007+01:00

Today with my colleague Luca Pucacco i've searched a method to detect which (junit) test are slow without any known or reasonable motivation. When you run a junit suite with eclipse you can see the execution time but you are not able to see an order.
So:

export Test run with the gui; let's call this file SuiteOutput.xml
Open a shell and write:
cat SuiteOutput.xml | grep "<testsuite" | sed 's/$.*time="$$[^"]*$$.*$/\2\1\2\3/' | sort -rg

With cat SuiteOutput.xml | grep "<testsuite" you are simply extracting the interesting rows
With sed s/..../../ we are going to substitute something. In details. Let's assume a row is in the form of:
<testsuite name="xxxTest" time="10.0">
The first group (.*time="\) is the first part of the row ( <testsuite name="xxxTest" time=" )
The second group ([^"]*\) is all before the " character ( the 10.0 string)
The last group is the rest ( ">)

The final row contains as the first information the execution time. The last operation is sorting these data by evaluating it like a number and not like a string.

[Quiz] what's the meaning of this symbol ?

2009-12-10T18:20:00.001+01:00

[Life] productivity and overtime

2009-12-10T17:54:00.002+01:00

How to be professional. What's the meaning of professionalism.
I cannot give a whole definition. I can say a clear example of fake professionalism: overtime.

Most of the times, if you need to work on sunday or saturday, it means you are not able to complete your work in a given time. The first thing to do is to acknowledge that this situation is the consequence of one or more failures.

Instead of working 24/7 to reach some goal you should try the opposite strategy: reserve some free time to think about the process and why you need to work hard.

I read this suggestion from this interesting article: Making Time Off Predictable - and Required

People can show their energies only in presence of limits.
I remember "The Legend of 1900" of Baricco:
"That keyboard is infinite... and if that keyboard is infinite, then on that keyboard there is no music you can play. You're sitting on the wrong bench... That is God's piano" and the conclusion:
"Take piano: keys begin, keys end. You know there are 88 of them. Nobody can tell you any different. They are not infinite. You're infinite... And on those keys, the music that you can make... is infinite. I like that. That I can live by..."

[Code] subset duplication

2009-12-09T15:27:00.006+01:00

One of the step in test driven development is "refactoring your code".
One of the main step of refactoring is the act of removing duplication.
You can read from wikipedia: "The concept of removing duplication is an important aspect of any software design".
I think duplication is pretty difficult to identify; there are a LOT of different kind of duplications. Some of them are stated here.
Today i notice another kind of duplication, something i can call like 'subset duplication' where a function does a little less of another bigger function.

For example:
addTicket(id, value) and
addTicket(id, value, comment) and
addTicket(id, value, date)

I think it's better to have only one function without say the same thing in one thousand of little different modalities. I like expose the differences, not hide them.
One solution could be addDefaultTicket() that return a ticket so you can customize with fluent interfaces: addDefaultTicket().withComment("xxx").
I think there are plenty of other solutions, but the point is always the same: trying to find the best and unique solution.

[Test] how to measure the execution time of Fitnesse tests

2009-12-02T11:39:00.004+01:00

We are using Fitnesse as our current acceptance testing framework.
1/3 of our tests are built upon a fixture that uses Selenium.

Selenium is the worst test framework i never known. It's hard to write, hard to maintain, it's hard to read and, most of all, is SLOW, absolutely slow.

It's a long time that i wish to know how much time our selenium tests needs to be run but fitnesse doesn't say this information.

The solution is to call via http get the url with the instruction to run your suite and measure its execution time. Then i move all selenium tests in a dedicated suite.

And here you can see:

time wget http://localhost:8181/XXXProject.SeleniumSuite?suite

real 6m56.227s (!)

God save us

[Script] subversion diff ignoring white space

2009-12-01T14:29:00.003+01:00

Try it when you need to look differences in your code without noise due to formatting rules:

svn diff -x "-u -w" (-r revisionNumber)

and eventually : 

patch -p0 -l < (file name)

----
Thanks to Marco Gulino

[Test] Parameterized tests

2009-11-24T09:37:00.002+01:00

I never used a not-well-known functionality of junit 4. I mean: the Parameterized tests.
Every time i extract a method called "verifyXXXwith(parameter)" and i create a lot of small test case.
Reading this article: http://www.testearly.com/2007/04/13/take-heed-of-mixing-junit-4s-parameterized-tests/ i think my solution is the best.
What's your feedback?

[Citazioni da me stesso] spazzatura

2009-11-13T17:25:00.003+01:00

"Basta mettere un cestino e la spazzatura arriva"

[Performance] Analyzing database performance

2009-11-06T18:27:00.005+01:00

Ok, it's time to release your software product in a production environment !
You need to analyze your database and collect some data, just to know what are the most problematic queries.
I read this interesting article by Tom Copeland
but it's pretty old.

Let's follow these instructions:

your dabatase should log all the queries executed. My db is postgreSQL 8.3, so:

sudo vim /etc/postgresql/8.3/main/postgresql.conf and edit:

log_statement = all
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'

sudo /etc/init.d/postgresql-8.3 reload

cp /var/log/messages log.txt

(i start to clear my file with this: grep -v "CET DETAIL" log.txt > log.txt)

grep select log.txt | cut -d ' ' -f 13- | sort | uniq -c | sort -nr | less (execute it without some pipe to understanding the meaning)

Now you know what are the most famous queries.
My suggestion is to start from here, adding custom data in used tables and executing the first two or three queries found before.

[Test] The fifth wicket secret

2009-11-04T16:27:00.004+01:00

Some time ago my coworker Alessandro Novarini had explored a way to test ajax events inside wicket tests. Look here !

Now you can explore another secret.
With this method you can see ALL the wicket paths you need to provide in your tests:


 public void printAllComponentPaths() {
    Page p = tester.getLastRenderedPage();
    p.visitChildren(new IVisitor() {

       @Override
       public Object component(Component component) {
          System.out.println(component.getPath());
          return null;
       }
    });
 }

[Public Speaking] a nice joke

2009-10-26T09:28:00.003+01:00

A man goes into a doctor's office and says "Doctor, doctor, it hurts when i raise my arm over my head" . The doctor replies, "Then don't raise your arm over your head!"

It's a nice metaphor :)

[Xp] switch and pair programming

2009-10-21T12:55:00.006+02:00

The working day starts with a stand-up meeting.
One of the key points is define the daily plan: who is working on what.

Sometimes i hear: " today i don't want to switch pair, i want to continue to work with the same coworker "

I think it's exactly the time when the switch is necessary.
I think the pair is working in a comfortable area; he know that his solution is not the best, but it works for the current task.
Probably he neither want to describe his problem nor to share his solution.

The bells are ringing!

[Future] electricity

2009-10-21T09:18:00.002+02:00

when apple will invent the wireless electricity ?

[Music] una delle migliori musiche

2009-10-07T23:09:00.004+02:00

L'ho ballata anche come se slow fox. Il testo è stupendo e il ritmo armonioso:

http://www.youtube.com/watch?v=CPzagqJy7e8

Luna tu
Quanti sono i canti che risuonano
Desideri che attraverso i secoli
Han solcato il cielo per raggiungerti
Porto per poeti che non scrivono
E che il loro senno spesso perdono
Tu accogli i sospiri di chi spasima
E regali un sogno ad ogni anima
Luna che mi guardi adesso ascoltami

Luna tu
Che conosci il tempo dell'eternitá
E il sentiero stretto della veritá
Fa piú luce dentro questo cuore mio
Questo cuore d’uomo che non sa, non sa

Che l’amore puó nascondere il dolore
Come un fuoco ti puó bruciare l’anima

Luna tu
Tu rischiari il cielo e la sua immensitá
E ci mostri solo la meta che vuoi
Come poi facciamo quasi sempre noi
Angeli di creta che non volano
Anime di carta che s'incendiano
Cuori come foglie che poi cadono
Sogni fatti d’aria che svaniscono
Figli della terra e figli tuoi, che sai

Che l’amore puó nascondere il dolore
Come un fuoco ti puó bruciare l’anima

Ma e con l’amore che respira il nostro cuore
E la forza che tutto muove e illumina! . . .

[Life] Idee geniali per nuovi progetti di business

2009-09-18T15:18:00.003+02:00

Ecco delle idee di progetti che vorrei vedere realizzate nel mondo. Se qualcuno ha intenzione di lavorarci mi faccia sapere :)
Le idee sono free, nel caso diventiate ricchi avrete l'obbligo morale di offrirmi una birra :)

Bid and prey

Tutti i nuovi sistemi di 'aste al ribasso' si basano sull'idea che l'utente tenta di indovinare il prezzo finale e si aggiudica il premio purchè la sua offerta sia la più bassa tra quelle fatte dagli altri utenti e l'unica. Ad esempio per un mac book un utente può offrire 89 centesimi, ma se quell'offerta è già stata fatta da un altro nessuno dei due può vincerla: bisogna provare un altro numero.

Ciò che mi piacerebbe è un sistema dove compro quote di vittoria assicurate. Ad esempio per lo stesso mac book di sopra vorrei comprare l'1% di probabilità di vittoria. Tutti gli slot di probabilità sono in vendita, ma non in modo lineare: comprare l'1% di un premio il cui valore reale è 100 Euro potrebbe costare 1 Euro mentre comprare il 5% dovrebbe costare un po' di più di 5 Euro. Per invogliare l'utente che ha perso a giocare ancora, gli vengono regalate quote su altri prodotti gratuitamente.

L'unico dubbio che ho riguarda il principio del gioco stesso: la gente che gioca al superenalotto lo fa perchè non conosce quante probabilità ha di vincere? E se tale probabilità fosse scritta su ogni biglietto?

Gruppi di Acquisto on line

Mi piacerebbe un sito dove mi collego e vedo cosa hanno intenzione di comprare i gruppi di acquisto vicini a dove abito. Ad esempio posso collegarmi e vedere che il gruppo di acquisto della mia zona ha in piano di acquistare da un allevatore di fiducia un gran numero di affettati. Vedo i prezzi e mi prenoto per la quantità che desidero.

Tutto nasce dal desiderio di avere prodotti di qualità a prezzi modici grazie al concetto di filiera corta

Dieta Guidata

Mi collego ad un sito di un supermercato, ad esempio Esselunga, e seleziono diete adeguate al mio profilo, eventualmente create direttamente da un dietologo esperto.
La spesa mi arriva a casa con i prodotti selezionati dalla dieta, così che io non abbia tentazioni e sopratutto eviti la difficoltà di selezionare quantità precise.

PanBigBrother

Vendere tessere che garantiscono l'accesso alla visione di webcam di altri utenti, sempre attive e fornite al momento dell'abbonamento. In pratica installi la tua webcam in casa, la tieni accesa quando e quanto vuoi. C'è un sito in cui navigare tra le varie utenze per scoprire dove si vuole scatenare la propria passione vojeour-istica.

BuyFreeTime

Noi occidentali manchiamo di tempo libero. Il sito prevede l'inserimento di richieste di commissioni da svolgere, con allegato il prezzo che si vuole pagare per averlo realizzato. Ad esempio: voglio comprare i biglietti del teatro ma non ho tempo nè voglia per farlo; dopo aver inserito l'annuncio si presenta un ragazzo che a fronte di un piccolo pagamento provvederà a fare la file, acquistare e riportarmi i biglietti. Ovviamente tutto è garantito da un sistema di feedback a-la ebay.

[Metodo] i falsi miti del Customer On Site

2009-09-15T17:43:00.004+02:00

Nel tempo ho rivalutato l'importanza della pratica 'Customer on Site' così sponsorizzata dai metodi agili quale ad esempio eXtreme Programming.

Mantengo valida l'assunzione che la collaborazione deve essere costante e collaborativa; gli sviluppatori dovrebbero smettere di arguire e approfondire l'analisi facendo domande e scavando per soddisfare i veri bisogni del cliente, così come il cliente deve continuare a definire le priorità etc...

Un'ottima opportunità sarebbe avere il cliente sempre disponibile. Ciò accade di rado, anche quando il customer è 'on site'. Spesso accade che bisogna rincorrerlo e farsi dare risposte mentre viaggia tra un meeting e l'altro. Questa modalità di ricevere risposte può sembrare agile ma porta con sè vari svantaggi: ogni scelta deve infatti essere meditata; non può essere frutto della fretta.

Avendo un filo diretto di comunicazione, il cliente è stimolato a fare richieste di change request, a volte piccole ma non certo trascurabili (magari una mezz'ora di tempo); la pratica suggerirebbe di raccoglierle e considerarle in una opportuna fase di planning; ed ecco un altro problema: non sempre il planning è definito in un certo lasso temporale ben definito. Ciò che ho visto spesso succedere è che il planning viene fatto al termine di una funzionalità, quando lo sviluppatore chiede su cosa deve iniziare a lavorare.

Riassumendo, il cliente non si abitua a destinare tempi ben definiti per il planning, per le demo, per l'analisi. Ritaglia questi tempi quando gli capita, e questo è un peccato per tutti.
Secondo me il lavorare a distanza fissando tali periodi di tempo potrebbe essere una buona soluzione. Planning lunedì mattina, le demo giovedì pomeriggio e l'analisi il venerdì, ad esempio.

E' certo possibile farlo anche lavorando dal cliente, ma entrano in gioco altre componenti: il cliente comincia a criticare le pratiche di sviluppo del team e vuole imporre una atmosfera di controllo. Comincia a questionare l'efficacia del pair programming, delle pause, degli orari di lavoro etc.. tutto questo per vari fini, che forse non è nemmeno interessante analizzare.

Se non c'è un coach oppure il coach non riesce a 'difendere' il team si creano tensioni che sarebbe meglio evitare.

Dalla mia esperienza preferisco mille volte non lavorare nella sede del cliente, pur mantenendo l'abitudine di comunicare spesso e bene.

[Fantasia] alcune previsioni sul futuro

2009-09-15T11:46:00.006+02:00

Uno dei metodi di previsione del futuro è quello di portare, con un salto di fantasia, all'estremo certe tendenze visibili nel presente.

Qual sarà la trasmissione TV più seguita fra qualche anno?

Il principio voyeuriestico verrà portato all'estremo: basterà comprare una tessera per diventare parte di una trasmissione globale. Con tale tessera, con varie forme di abbonamento, verranno fornite un paio di telecamere da piazzare in casa propria, o addosso. Grazie all'abbonamento si continuerà a mandare in streaming parte della propria vita (a orari prestabiliti o continuamente) e si avrà il diritto di guardare le altre telecamere degli altri utenti. La Tv selezionerà i top ten, o immagini varie, farà classifiche dei momenti più hot, o più imbarazzanti o più simpatici. A volte inviterà i protagonisti delle storie negli studios.
E' come se tutti gli abbonati fossero in una casa alla Grande Fratello.

Qual è il futuro di internet?

Mi pare che gli utenti da un primo grande entusiasmo in cui l'esplorazione del web era viva ed eccitante stiano passando ad un uso del mezzo più rilassato, più abituale. Da un punto di vista piu generale, si è passato da un paradigma delle amicizie 'da piazza' ad amicizie virtuali.
Senza troppo slancio di fantasia immagino che si assestino non più di 10 siti navigati puntualmente e ritualmente; tali siti sproneranno alle conoscenze virtuali ed agli incontri reali, che torneranno ad essere frequenti, probabilmente con un forte accento sessuale in prima istanza. Si eviterà quindi la mancanza di novità dovuta alla frequentazione delle abituali amicizie senza però perdersi nella vacua virtualità.
Spingendosi un po' oltre, si incontreranno persone nuove sempre più spesso, e gli incontri saranno numerosi ma rapidi; il momento diverrà eterno e l'attuale dissidio dovuto all'indossare una maschera ed essere sè stessi in momenti diversi verrà risolto diventando altro in ogni momento

[Metriche] Le uniche metriche del codice che servono sono qui

2009-09-08T20:33:00.007+02:00

Molto si è detto e scritto circa quali metriche è opportuno considerare durante lo sviluppo di un progetto.

Poichè le metriche servono esclusivamente a incoraggiare un comportamento, trascrivo qui quelle che piacciono a me, seguendo le quali si riuscirà a diventare un ottimo programmatore.
Seguitemi:

> Minimizzare il numero di user stories lavorate in modalità Last In First Out
Quando l'ultima user story descritta è sempre la più importante vuol dire che non c'è un vero e proprio planning e si è perso qualsiasi concetto di pianificazione e priorità: il vostro progetto sta andando a ramengo.

> Profondità coverage
Sapere che l' 80 % del codice è testato è una buona cosa. Eppure sapere che dalla stessa riga di codice ci passano più test in generale può voler dire che sono stati scritti non solo dei test unitari, ma anche dei cluster test o degli integration (o acceptance) test.
Se due test di diversa natura passano dalla stessa riga di codice la profondità di coverage è 2, che è meglio di una profondità di 1.

> Massimizzare la varietà di dati di test (suggerita dal mio collega Marco Gulino)
Non siamo abituati a pensare alle boundary conditions. Un eventuale codice del tipo: if (i < i ="=" i =" MAX_INT" i =" -1" style="font-weight: bold;">> Monitorare il rapporto Errore di stima / Numero di framework usati

L'errore di stima cresce a seconda del numero di tecnologie attraversate. Per completare la vostra user story dovete toccare solo maven, java, spring ? Oppure anche hibernate, fitnesse, wicket, selenium etc..? Calcolate un fattore correttivo adeguato!

> Duplicazione divergente
Certo la duplicazione è un male: ogni modifica in un codice copiato va riportato paro paro da altre parti e tale processo è error-prone, ma alcuni eroi con un po' di lavorio con search&replace e espressioni regolari riescono senza dubbio a lavorare in questa modalità. Eppure se i pezzi di codice duplicato divergono si perde la capacità eccezionalmente umana di riconoscere ad occhio le differenze. Il tuo codice non solo è duplicato ma non è più nemmeno simmetrico!

> Il rapporto Numero di classi / Numero di metodi pubblici deve tendere a uno
Una classe, una responsabilità, un solo metodo pubblico. E' facile identificare di quante responsabilità è caricato un oggetto: il piu delle volte basta contare il numero di metodi privati

> Il tempo di esecuzione test non deve degenerare all'aumentare del numero di test
Per lo meno garantisci che rimanga costante al crescere del numero di test. 100 test ci mettono 100 secondi? Se 200 test ci mettono 200 secondi stai adottando una strategia non peggiorativa.

> Minimizzare il numero di user stories che tornano "in progress"
Non mi ricordo chi l'ha detta, ma è di certo sintomo che gli AT non sono efficaci, e rilavorare funzionalità considerate finite è frustrante e puà essere dannoso se chi sistema i bachi non coincide con chi ci ha lavorato.

[Citazioni da me stesso] sulle scadenze

2009-07-23T17:28:00.003+02:00

"Sarà tutto disponibile entro ma non prima dei 5 minuti"

[Citazione] da fabiana

2009-07-22T17:52:00.003+02:00

"Se la gente mi giudicasse per i film che ho visto
vivrei da sola in una palude deserta"

---

"E' come chiedere al cliente se preferisce la Nutella o i broccoli al vapore"

[Sogno] Racconto di un sogno: la bomba della vita

2009-07-19T19:35:00.004+02:00

Il racconto di un sogno.

Ero a Pavia a casa dei miei genitori, nella mia stanza, un week end assolato.
D'un tratto vivo la tremenda esperienza di un terremoto, assai vivida nel mio sogno.
Un rumore sordo seguito da una sensazione di lotta del condominio che stava cercando di non crollare su se stesso. Tutto ai piani inferiori si stava sgretolando e cedendo in una direzione. Fuori una luce molto piu luminosa del solito.
Dopo una decina di secondi tutto è finito, il mio primo pensiero è per i miei genitori. Ci ritroviamo tutti nel corridoio, piangenti e ci abbracciamo per la paura e la gioia di ritrovarci vivi.

Guardo fuori dalla finestra della mia camera e noto che dal terzo piano siamo all'altezza del primo, tutto sotto di noi è ceduto.
Nella mia stanza per terra c'e' un piccione che maltratta un passerotto in pessimo stato che non riesce a volare. Per lo schifo con la paletta li lancio fuori dalla finestra, e noto che anche fuori riprende la lotta tra i due.
Nell'istante in cui ho aperto la finestra entra un ragno grosso la metà di una mano. Con una ciabatta lo schiaccio e lo uccido, ma dal suo corpo morto si generano altri ragni piu piccoli che cominciano a camminare sulla finestra. Guardo quindi fuori e mi rendo conto di cosa è successo: è stata lanciata una bomba di vita.
In pratica tutto intorno a me la vita era esplosa, la vegetazione aveva ritmi vertiginosi e nel breve la città sarebbe diventata una specie di giugla. Gli animali si generavano a una velocità pazzesca e la lotta per la vita e per le risorse si sarebbe fatta ardua.

Dopo alcune ore capisco che non ha piu senso stare chiuso in casa e rifiutare la nuova realtà; convinto che sarei morto a breve, esco per strada pronto ad incontrare il mio futuro.

Entro pochi istanti mentre camminavo per strada tante formiche volanti si posano sul mio corpo e lo proteggono. Non so qual è il motivo che le ha spinte, forse il calore del corpo, ma da quel momento si crea un rapporto simbiotico tra me e questi animali: loro mi difendono dalle minaccie e io li ospito.

In quel momento capisco che era inutile avere paura della nuova realtà. Il sogno finisce.
Chi me lo interpreta ? :)

[Citazione] junior e senior

2009-07-16T11:30:00.003+02:00

2 junior non fanno 1 senior
ma anche 2 senior non fanno 1 junior

[Citazione] Andrea e la parmacotto

2009-07-08T17:57:00.002+02:00

Andrea a pranzo:
"Ho sempre sognato fare il sito per la Parmacotto, così potrei fare la user story 'prosciuttoCRUD'"

-----
Note:
CRUD = http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

[Citazione da me stesso] Tradimento

2009-07-08T17:54:00.002+02:00

"...quando ho letto la mail ho pensato: 'anche tu, Giuda, figlio mio' "

[Citazione da me stesso] Bachi

2009-06-29T16:53:00.003+02:00

Non ci sarebbero bachi senza gli utenti!

[Test] Terzo (e ultimo) segreto di wicket

2009-06-22T15:36:00.005+02:00

System.out.println(tester.getServletResponse().getDocument());

[Test] Secondo segreto di wicket

2009-06-22T12:13:00.003+02:00

Dopo il primo segreto, hai aperto le porte del secondo segreto per testare wicket:

DropDownChoice yourDropDown = (DropDownChoice) tester.getComponentFromLastRenderedPage(wicketPath);

assertEquals(expected, yourDropDown.getModelObject());

[Test] Primo segreto di wicket

2009-06-17T10:33:00.003+02:00

Aziona il tuo wicket tester:
tester.startPage(YourPage.class);

e poi recupera dalla root la tipologia di ogni componente introdotta:

tester.assertComponent("form", Form.class) -> barra verde
tester.assertComponent("form:table", ...) -> barra verde
tester.assertComponent("form:table:rows", ...) -> barra verde
.... -> barra verde
tester.assertComponent("form:table:rows:1:cells:2:cell:select", DropDownChoice.class); -> barra verde

[Citazione] una paziente al suo psicologo

2009-06-04T09:24:00.004+02:00

"La psicologia è come la crema anti rughe, puoi dire solo se non ha funzionato"

[Citazione da me stesso] Trasparenza

2009-06-01T12:13:00.003+02:00

"Andrea, non è che manco di trasparenza. Io sono trasparente come un lago cristallino increspato dalle onde"

[XP] Principi di sviluppo di Tommaso Torti

2009-04-20T23:33:00.003+02:00

In questi anni di lavoro come extreme programmer ho avuto modo di provare su pelle molti dei principi, valori e pratiche che si leggono su libri.

Le ho sperimentate principalmente in due team, l'ex Xplayers team di Quinary e l'attuale team Orione di Sourcesense.
Altre volte le ho affinate nei gruppi in cui mi sono trovato a fare mentoring, negli scambi epistolari con la mailing list di xp-it e nel xp-user group di Milano.

Ho così coniato dei miei slogan; condivido con voi i principi vertuosi così come li ho interiorizzati.

1) Assolutamente al primo punto e con ampia distanza da qualsiasi altro:
UNA SOLA PARENTESI APERTA

Vuol dire: fai una e una sola cosa alla volta.
Si concretizza nelle pratiche:

frequenti commit, che vuol dire darsi la possibilità di sbagliare e fare revert senza pietà. Aimè sono pochissime le persone che fanno revert e che ignorano la potenza del fare un passo indietro per farne due aventi.

distinguere bene quando si scrive codice da quando si rifattorizza.

l'uso della TODO list, anch'esso rarissimo. Quando mi capita di finire la mia funzionalità prima di prenderne una nuova chiedo ai miei compagni di team se hanno tasks che posso completare delle loro user stories. Li vedo sempre impacciati nel darmi una risposta chiara e concisa.

Se si mantiene una sola parentesi aperta, tutto ciò che è extra va a finire su un pezzo di carta. Quali vantaggi? Ci si dà la possibilità di dare priorità, di alternare le attività secondo le energie del momento etc.

2) DARE ALMENO 3 SOLUZIONI AD OGNI PROBLEMA
E' necessario ampliare lo spazio soluzione di ogni problema. Ciò che accade è che spesso si scelgono le soluzioni meno pulite perchè non si conoscono alternative. Se non si riescono a trovare alternative bisogna sforzarsi di farlo.
Come? Chiedendo in mailing list, scoprendo come altri hanno risolto lo stesso problema, come si risolve in letteratura, confrontandosi con colleghi piu esperti etc.
L'applicazione di questa pratica è una grande accelerazione nella carriera che porta uno junior a diventare senior.

3) IL CODICE DEVE ESSERE SIMMETRICO
Cosa non va nel seguente codice?

if (aa instanceof Father) ....
if (aa instanceof Mother) ....
if aa == null ....
if (aa instanceof Object) ....
E' una chiara violazione del paradigma object oriented ma sopratutto stona da un punto di vista prettamente estetico. La precondizione di ogni refactoring è la sensibilità, e la simmetria è uno dei modi per aumentarla.
Ho in mente l'immagine di tempio greco, dove le colonne sono di ugual numero a destra e a sinistra dell'entrata ed hanno stessa altezza. Il codice deve rispecchiare tale simmetria per essere elegante.

4) IL PROBLEMA DEL TDD E' IL TERZO PASSO
Non c'è niente da fare, il refactoring ad OGNI barra verde è difficilissimo dal punto di vista della disciplina. Si tende a scrivere altri test case, a rifattorizzare 'alla fine'. Quel che accade è che i refactoring sono sempre più grossi del necessario e si procede lentamente; inoltre non è raro lasciare debito tecnico.
Quando lo si vede? Quando ad esempio per scrivere un nuovo test case duplico uno esistente, e magari mi sembra anche giusto! Wrong!
Non c'è soluzione precisa a questo errore, ci vuole solo grande disciplina.

5) COMBATTI LE BATTAGLIE GIUSTE (ABBANDONA TEMATICHE ESTETICHE )

In un team ci sono sempre punti di vista differenti, ma bisogna scegliere la battaglia da combattere.
Sopratutto vale la pena concentrarsi sugli argomenti davvero sostanziali. Un tipico esempio sono le battaglie per l'uso dei generics o per l'introduzione di getter e setter.
Un altro esempio personale è la preferenza verso le stime in termini temporali rispetto alle stime con punti complessità. Ho le mie motivazioni, teoriche e pratiche, che mi portano a favorire una soluzione rispetto all'altra, ma reputo che non vale la pena combattere. A volte le persone hanno bisogno di sbagliare. Eppure il vero valore delle stime è rendersi conto del lavoro che c'è da fare, dei rischi associati, degli eventuali split etc., in fondo non è _così_ importante combattere questa battaglia (anche se so di essere nel giusto :) )

Questo vuol dire scendere a compromessi, che è una qualità e non un difetto di un programmatore che lavora in team.

6) NO SILVER BULLET

Mai adottare un atteggiamento del tipo: "non si fa così", o "si deve fare così".
Tale fanatismo è facilmente presente negli agilisti, ed è il primo pensiero che mi viene quando nascono dei movimenti di pensiero tipo quelli per l'adozione della tecnica del pomodoro o della campagna anti-if.
Non è così raro incontrare punti di vista assoluti, che ammazzano la libertà, il divertimento e sopratutto l'efficacia dello sviluppo in nome di principi ragionevoli.
Esempi: "non ci devono essere new nel codice" , "non ci devono essere check sul null nel codice", "no warning nel progetto", "solo test con mock" , "sempre loggare questo e quest'altro", etc etc

7) TUTTO CHIUSO A FINE GIORNATA
Per chiudere il cerchio, una variazione del punto 1. Una giornata non è che una singola parentesi all'interno dell'iterazione. Quindi: nessuna modifica non committata sulla macchina di sviluppo, il sistema di integrazione continua è verde con l'ultima versione rilasciata, il journal è stato scritto, il tracking è stato completato, le carte sono sulla lavagna etc etc.

Ovviamente ci sono le dovute eccezioni e la capacità di non cadere nel fanatismo (punto 6) sono tante. L'importante è tendere all'eccellenza ed evitare di mettere sul tavolo troppi compromessi.

[Script] verifica che nel tuo war non finiscano diverse versioni della stessa libreria!

2009-02-05T14:25:00.003+01:00

#!/bin/bash

warfile=$1

function strip_version_numbers() {
# converte foo/bar-1.2.3.jar in foo/bar.jar
ruby -pe 'gsub($1, "") if $_ =~ /^.*(-[0-9.]+)(-bin)?.jar/'
}

# check there are no duplicates entries in war
if jar tf $warfile | strip_version_numbers | sort | uniq -c | sort -nr | head | grep '^ [2-9]'
then
echo "duplicate entries found"
exit 1
fi

Buddismo, Ballo, Lavoro

2009-02-05T01:30:00.003+01:00

Cosa cerco nella gente che viene a fare i colloqui? La passione per il lavoro che faranno! E non è facile all'interno di un colloquio scovarla; si deve vedere l'occhio brillante e una leggera pazzia quando si tocca un argomento interessante per il candidato. Come si fa a lavorare senza passione? Bisogna ritrovare il senso della parola 'passione', anche dal punto di vista della sofferenza.

Ogni lezione di ballo è pura passione, è un abbattimento di qualsiasi tipo di orgoglio, una presa di coscienza della propria incapacità ma anche una speranza di arrivare verso vette migliori, diminuendo i difetti e portando al massimo i pregi.
Lo stesso messaggio arriva da tutti i miei maestri. Recalcati, Ikeda, Vaccari, tutti tendono a bastonare, ad incoraggiare e moooolto raramente si complimentano. Il loro fine è portare al massimo le proprie capacità che sono estremamente maggiori di quello che la nostra mente pensa. I limiti che ci imponiamo sono enormi, agghiaccianti.

Il messaggi che ci arriva dai maestri è che tutto è lotta e fatica, e passione, e competizione. Ma il messaggio che può apparire cattivo è invece una profonda sfida verso una vita ricca di soddisfazioni. Solo controcorrente ci si diverte a remare, solo vincendo una importante gara si è soddisfatti (ballo), o lottando contro una propria paura (buddismo), o consegnando software di qualità (lavoro).

Recalcati non si limita a bastonarti: ho il corpo troppo debole per ballare: ho muscoli delle braccia e addominali atrofizzati, e questo genera tanti problemi di cui non riesco ad accorgermi.

Ikeda ammonisce sulla oscurità della vita che in fondo è il non credere nelle proprie capacità, il 'non ce la farò mai', il 'non ci provo neanche', e il 'io ce l'ho messa tutta ma sono gli altri'.

Vaccari puntualmente spinge affinchè le funzionalità siano sviluppate e mandate in produzione, senza seghe mentali inutili.

Guardate ad esempio l'elenco di ciò che si è trattato nella odierna lezione di ballo :

quando si va indietro le ginocchia piegano in avanti
l'effetto swing nel giro a destra
immaginare la pressione sulla schiena che spinge in diagonale dall'alto verso il basso mentre si va in avanti e dall'alto verso il basso sul petto mentre si va indietro
una sola anca è ammessa fuori partner in ogni momento
l'effetto di scatto nell'apertura del tango è data da un leggero slittamento del busto a destra prima dello 'strappo' a sinistra
la followy è in linea di ballo, girata di 180 tra la fine del primo passo e l'inizio del secondo
mettere una pressione mostruosa sull'alluce del piede sinistro, girato verso l'interno coscia, nei link del tango al fine di bloccare il movimento rotatorio
il conteggio del fleckerl nel valzer viennese è : 7 di giro destra, 8 di cambio, 1-2-3-4 di giri a sinitra verso il centro, 5, 1, 2 (incrocia indietro), 6, 1,2 (sempre avanti), 7,1,2 (incrociato dietro) 8 di check, indietro e riprendere con i giri

Un elenco enorme, e se anche 1 solo punto fosse per sempre interiorizzato sarebbe un ENORME passo avanti!

Lo studio, l'allenamento, la volontà e l'umiltà sono alla base di qualsiasi percorso. Ed alla fine di ogni tappa bisogna sentirsi stanchi, a volte soddisfatti e a volte no, ed anche speranzosi.
Cerco di farlo anche a lavoro. Per me la tappa è una commit nel repository, una consegna di un pezzo minimale di funzionalità, che tendo a fare ogni ora circa. C'è gente che non è focalizzata sul prossimo passo, rimette in discussione tutto e non combina niente. Ogni passo , come ogni istantanea di ballo, deve essere perfetta di per sè. La tecnica è alla base della bellezza.

E in fondo tutto ciò che cerco è la bellezza. La bellezza di un ballo, che si perde se non c'è tecnica ma anche se non c'è eleganza. Ho visto coppie che ballano tecnicamente benino distruggere ogni immagine di sè per come trattano il partner o perchè ballano con la cicca in bocca. La bellezza della recitazione buddista, con il ritmo della voce, l'incenso, l'acqua, le candele, e quel senso estatito di contemplazione dell'universo attraverso un foglio di carta. E anche la bellezza del codice scritto, che sì deve essere pulito ma anche simmetrico come un tempio greco e si deve leggere come si legge una fiaba dei Grimm, sapendo che c'è un lieto fine :)
Come fare a capire se si sta procedendo giustamente?
Ogni tappa deve essere seguita da una sensazione positiva ma con una leggera insoddisfazione. Ogni ballo, anche il migliore, ha sempre almeno un passaggio che poteva essere svolto meglio. Ogni recitazione buddista deve avere un effetto benefico; che non vuol dire necessariamente essere felici; a volte vuol dire essere aspri, irati come un leone che sta per azzannare una preda, cioè la voglia di superare una paura.
Ogni lavoro deve terminare con un po' di stanchezza, di soddisfazione per il codice scritto ma anche con una visione di qualcosa migliore.

E se non si procede giustamente che si deve fare?
Nel buddismo si dice che ogni pensiero, azione e parola genera una causa di un effetto che prima o poi si manifesterà. Questo è il karma. Attraverso la volontà di fare meglio, lo studio in 'ambiente protetto' (che è l'allenamento di ballo nella propria scuola ad esempio o la pratica dello studio nel lavoro o i meeting di gruppo nel buddismo), e lo sfidarsi nella realtà, vendendo cara la pelle :) Eppure tutto nasce dalla determinazione, cioè dal proprio io.

Ed ecco giunti all'essenza: ogni problema è al 99.9 % legato alla volontà della persona. La paura nel ballo è molto chiara e non c'è bisogno di spiegarla. Forse è nel lavoro piu difficile vedere questo pattern. Ed ecco l'effetto 'gruppo di ascolto' che vedo così chiaro nella comunità agile, cioè la tendenza alla lamentela verso tutti: i clienti, i colleghi, la tecnologia, mai verso sè stessi.

Tutto nasce da un attestato di incapacità e dalla voglia di migliorarsi.

[Agile day] Results day

2009-01-30T14:48:00.003+01:00

Negli ultimi 2 mesi sto lavorando in un team di agilisti, come Lorenzo Bolzani -neo-fondatore del gruppo Scala User Group di Milano-
Daniele Della Fiore -esperto di usabilità e comunità 2.0- ed altri su un progetto il cui codice è scritto in modalità Domain Driven Design

Cerchiamo di applicare i principi xp nel lavoro day-by-day, ovviamente incontrando difficoltà legate al planning, al codice, alla condivisione di informazioni.
Proprio su quest'ultimo punto abbiamo avviato una ricca discussione circa la modalità di condivisione delle informazioni.

La pratica di scrittura del journal la sera prima di uscire era poco applicata; pochi scrivevano un summary della loro attività quotidiana e
(ancora peggio) pochi le leggevano.
Discutendo dei motivi è emersa l'esigenza di provare qualcosa di nuovo! Il wiki interno è come il codice, e per essere utile deve essere rifattorizzato,
riveduto costantemente e aggiornato spesso.
Abbiamo notato che le informazioni piu importanti sono le ultime in ordine temporale e spesso è utile scrivere tante piccole note durante la giornata,
rispetto a un unico riassunto al termine, che spesso implica la perdita di tanti dettagli importanti.

Il successo è stato l'attuazione di una proposta di uso di un tumblr ; i post sono aumentati e globalmente c'è un flusso di informazioni di qualità.
Ci sono anche critiche a questa nuova modalità: non tutte le informazioni devono stare lì, c'è il rischio di perderle.
L'importante è provare e valutare dopo un po' come va!
Il mercoledì pomeriggio siamo soliti fare formazione interna. L'andamento dello studio però non ci soddisfaceva; il primo passo è stato studiare
argomenti piu legati al progetto, in modo da riusare nel breve la conoscenza acquisita. Ad esempio abbiamo approfondito wicket

Il secondo successo è stato provare uno studio a-la "etude" di Shore e Warden. Abbiamo quindi analizzato parti del nostro dominio, rivedendo il design
costruito nel tempo. E' stato un evento importante, il cui effetto è stato l'aver acquisito maggiore conoscenza di logiche di dominio e l'aver rifattorizzato
pesantemente la gestione del tempo e della formattazione del nostro progetto.

[Citazioni da me stesso] manager

2009-01-16T18:18:00.004+01:00

Io sono come Easy Mock, mando messaggi e verifico risultati

[Citazione da me stesso] definizione di test

2009-01-09T15:42:00.001+01:00

I test sono un attestato di incapacità.

[Citazioni da me stesso] revert

2008-12-01T18:17:00.000+01:00

Non si reverta l'acqua col bambino

[Weblogic] how to redeploy from an ant file

2008-11-03T15:34:00.002+01:00

Includi weblogic.jar nel tuo progetto.

Personalizza il seguente target ant:

[Agile] esperimento sulla precisione delle stime nei progetti agili

2008-09-10T17:54:00.001+02:00

Fatto: All'inizio di ogni progetto il cliente chiede una data di consegna e i termini del contratto vengono decisi sopratutto sulla base delle stime fatte dagli sviluppatori.

E' quindi importante stimare minimizzando gli errori. Attualmente le tecniche di stima sono rozze e imprecise. Spesso si sottostima del 30% circa (dati calcolati su diversi team in diversi progetti).
Nel libro 'Agile Estimating and Planning' di Mike Cohn ne vengono citate alcune: Expert Opinion, Estimating by Analogy, Disaggregation, Planning Poker. Inoltre i team agili usano due principali unità di misura: stima in tempo ideale (al netto di impegni lavorativi extra-progetto) e in punti complessità.
Una mia ipotesi è che l'unità di misura usata influenza l'errore di stima con un fattore significativo. I punti complessità hanno molti vantaggi, ma dal punto di vista di minimizzare gli errori di stima in fase di analisi del progetto sono uno strumento assai impreciso.
La teoria psicologica è che l'uomo riesce a stimare meglio considerando le relative complessità. L'esempio classico riguarda la stazaz di alcune razze di cani: è difficile indovinare il peso ma è facile dire che un san bernardo è 4 volte piu grande di un bulldog.
Pur approvando intuitivamente tale ipotesi, penso che debba sempre essere verificata nel contesto applicato. Ad esempio quando faccio la spesa alla cassa 'indovino' la somma da pagare con un piccolissimo errore di stima, minore del 10% il piu delle volte. E nel mio processo non dico '1 kg di arancie costa 1.5 volte due etti di prosciutto crudo'. O ad esempio se devo indovinare il peso di una persona non penso a quanto è piu grossa o piu piccola rispetto a me.

Ma alla fin della fiera penso che qualsiasi strumento si usi per stimare si debba uscire dalla mentalità 'artistica' per dare un carattere scientifico. Propongo il seguente esperimento: avendo dei dati oggettivi, due gruppi separati usano l'unità di misura assoluta ideale oppure i punti complessità. Si valutano alla fine gli errori. Alcune persone si sentono a loro agio usando una unità di misura o l'altra, probabilmente è meglio che i gruppi si formino volontariamente.

Con questo esperimento oggettivo, dove i dati sono verificabili, penso si possano raggiungere conclusioni interessanti. Ad esempio potrei valutare la tecnica che un tempo ho usato, con particolare profitto, che prevede una suddivisione orizzontale, per layer tecnologici. Ogni user story attraversa diversi livelli tecnologici. Ad esempio:

codifica del dominio applicativo in sorgenti java/ruby ...
file di properties
database
chiamate a sistemi esterni
test di accettazione
deploy
aggiornare il processo di build etc.

La stima è una combinazione della complessità e del numero di layer tecnologici per la competenza dello sviluppatore in ognuno di questi.
Ad esempio la prima carta avrà a che fare tipicamente con il setup dell'ambiente, con la creazione di script di build, un minimo di logica di dominio e un deploy sull'application server. Supponiamo di usare maven per la build, java per il dominio e jboss come application server. Poichè nulla è stato già implementato il costo sarà oggettivamente alto e fortemente dipendente dalla competenza in tutti e tre i layer.
Una analoga carta fatta dopo la prima release partirà da una situazione stabile, ed è probabile che lo sviluppatore abbia approfondito la conoscenza in almeno uno dei layer. Tenendo traccia dei layer attraversati e della tabella di competenza dello sviluppatore penso che si possa raggiungere una precisione di stima davvero ragguardevole.

Ovviamente senza un esperimento sono solamente fantasie.

[Shell] il primo script dalla command line di windows

2008-07-24T18:10:00.001+02:00

Il bisogno era di andare dentro ogni progetto in una certa directory ed eseguire un comando

for /D %G IN (tua_directory*) do cd %G & mio_comando

Ad esempio:
for /D %G IN (kernel*) do cd %G & svn st & cd ..

[Shell] find a file inside your yars

2008-07-11T16:56:00.000+02:00

Il prossimo tema d'esame di tutti gli studenti di Matteo Vaccari :)

for file in $(find . -iname \*.jar); do
if jar tf $file | grep "$1"; then
echo "Trovato! era in $file"
fi
done

Si legge da solo.

[Agile] Ecco a voi la migliore metrica sulla PRODUTTIVITA

2008-07-11T01:07:00.001+02:00

Sto cercando di riportare tutto al segno '-'.
La differenza, il concetto di togliere. L'agilità porta con se un insieme di buone pratiche ma la vera novità è l'insieme di principi: ce lo siamo detti così tante volte.
Aggiungiamo allora nel nostro elenco il principio di secchezza.
Perchè bisogna togliere tutto il codice commentato, tutto il tempo usato per scrivere javadoc, per scrivere test il cui fine è quello di superare delle metriche. Ci siamo abituati ad avere tutto, togliamo ai nostri sviluppatori la gui, diamogli il mouse per 10 minuti al giorno, giusto per staccare la testa. Togliamo loro potenza di macchine, non regaliamogli ram, nè cpu. Scriveranno software leggero o periranno. Impareranno ad avere confidenza sul codice senza lanciare un application server in locale. Bisogna togliere il journal se non è utile come lo si scrive, togliere il pair se uno dei due dorme, togliere i test di accettazione se il cliente non li scrive o non contribuisce a scriverli.

Manager di tutto il mondo alla ricerca della metrica perfetta sulla produttività, qui c'è la vostra risposta: obbligate i vostri sviluppatori assetati di risorse a scrivere file non piu grandi di 5K, vedrete magie. E non parlo solo di codice, ma anche di configurazione.

E' solo in ristrettezze di risorse che si aguzza l'ingegno.

Togliamo il tempo agli sviluppatori e chiediamo loro risultati se si distraggono con mail, giochi, messenger.
Dobbiamo sentire la rabbia quando duplichiamo: cancelliamo dal nostro vocabolario frasi come: "basta copiare questa cosa" e trasformiamole in: "CHE PALLE, devo anche copiare questa cosa". Basta "spero di farcela entro oggi"! Basta interi, dobbiamo dare risposte booleane: sì. no.
Quando il manager ci chiede se possiamo aggiungere user stories all'iterazione, quando dobbiamo decidere se prenderci il rischio di un nuovo progetto, quando dobbiamo scegliere se assumere o no una persona: SI o NO. Non c'è forse, non c'è magari.

Togliamo framework che fanno cose 'GRATIS', anzi, togliamo la parola 'gratis'. Togliamo la sacra famiglia del fallimento hibernate, struts, spring.

Sempre di piu aggiungiamo tecnologia per risolvere problemi, e ci inventiamo soluzioni barocche con generics, con annotations, con aspect oriented programming, con librerie di test con interfaccie fluenti. Siamo così alti sui trampolini della tecnologia che qualche settimana fa miei nuovi colleghi hanno dovuto fare uno spike su come si esegue una connessione jdbc pura in java per fare delle semplici query.
Non ci serve nulla di piu di una manciata di concetti sul paradigma object oriented. Altro che easy mock per esplorare come gli oggetti possono parlarsi: carta e penna! Anzi, togliamo anche carta e penna, lasciamo solo il cervello.

[Mac] switch java virtual machine script

2008-06-20T09:29:00.001+02:00

torti:~ tot$ cat switchjvm.sh
ROOT=/System/Library/Frameworks/JavaVM.framework/Versions
SOFTLINK=$ROOT/CurrentJDK
TARGETA=$ROOT/1.5
TARGETB=$ROOT/1.4
TARGETC=$ROOT/1.6
if [ `readlink "$SOFTLINK"` == $TARGETA ] ;then
rm $SOFTLINK && ln -vsf $TARGETB $SOFTLINK
elif [ `readlink "$SOFTLINK"` == $TARGETB ] ;then
rm $SOFTLINK && ln -vsf $TARGETC $SOFTLINK
else
rm $SOFTLINK && ln -vsf $TARGETA $SOFTLINK
fi
java -version

[Libri] citazione - arte e vita

2007-06-25T21:01:00.001+02:00

La gente dice che bisogna separare la propria vita reale dalla propria arte, che bisogna proteggere la propria vita reale dalla propria vita letteraria. In questo modo si soffre di meno e si vede il mondo con più sobrietà. Ma io penso che sia un atteggiamento molto egoista. Mi piace quello che Flaubert diceva dei Greci.Se sei un vero artista, tutto quello che c'è nella tua vita fa parte della tua arte. L'arte è un monumento della vita. L'arte è il percorso astratto dell'esistenza quotidiana
-----
da 'Piccolo Dizionario cinese inglese per innamorati'

[Libri] Recensione libro Release It! parte 5

2007-06-14T11:16:00.000+02:00

Ho saltato alcuni paragrafi: load balancing e clustering .
Altri consigli sparsi relativi alla sicurezza e al networking (uso
di ip virtuale, eseguire l'applicazione non come utente root..)

Configurazioni

Mettere al sicuro le password definite nei file di
configurazione. Mantenere i parametri di configurazione per l'ambiente di produzione in file a parte,
preferibilmente non nella directory dove è installata l'applicazione. Questo perchè probabilmente
quella directory viene sovrascritta ad ogni deploy, quindi è da evitare un nuovo editing di quei file
ad ogni deploy. Analogamente le property comuni a tutte le installazioni dovrebbero finire nello stesso file.
Usare nomi chiari anche per i parametri, ad esempio evitando hostname=XXX che è come scrivere integer=YYY

Start up e shutdown

Mi viene in mente la fase di startup di un sistema linux che mostra un elenco di risorse inizializzate.
L'idea è la stessa, è buona cosa avere un feedback sulla fase di inizializzazione delle risorse.
Inoltre nella fase di shutdown, così come in un negozio si aspetta che i clienti presenti escano
e non se ne fanno entrare di nuovi, l'applicazione dovrebbe smettere di accettare richieste e
terminare quelle running, ovviamente prevedendo un timeout per evitare shutdown infiniti.

Administrative Interface

Evitare gui, sopratutto in ambienti dove c'è una architettura applicativa orizzontale con più server.
Meglio interfaccie a linea di comando così che si possa usare in uno script.

Un altro succo del discorso:
"you can choose not to deal with these
issues during development. If so, you will deal with them in production...
time and time again. Dealing with these issues in development
does not necessarily cost much, in time or effort, and what it does cost
is far outweighed by the long-term cost of ignoring them"

[Libri] Recensione libro Release It! parte 4

2007-06-12T09:58:00.000+02:00

Capacity

Spassoso racconto introduttivo di una esperienza. Secondo me l'autore ha usato ATG, prodotto commerciale
per siti di commercio elettronico che ho usato anche io in un mio progetto. Nell'introduzione ho scoperto anche
la CONWAY'S LAW ovvero la legge secondo cui il software rappresenta il modello comunicativo che intercorre
tra i suoi sviluppatori. Giunge quindi alle

Due definizioni:
* "Capacity is fundamentally a measure of how much revenue the system
can generate during a given period of time."
*il massimo throughput che un sistema può sostenere per un certo carico mantenendo un tempo di risposta accettabile
per ogni transazione.
Si distingue dalla performance -la velocità di processamento di una singola transazione, misurata in isolamento
o sotto carico- e dalla scalabilità - il cambiamento di throughtput a seconda del carico -.
Il più delle volte è possibile aumentare la capacità tramite opportune modifiche al design del software piuttosto
che aumentando l'hardware.
Come ?

Identificando il collo di bottiglia, il VINCOLO che limita la capacità di tutto il sistema.
Ci sono in gioco le 'driving variables' cioè agenti fuori dal nostro controllo, come il tempo, le richieste degli utenti etc
che influenzano le 'following variables'. Queste possono essere misurate: uso della cpu, della memoria, della banda etc.
Il 'constraint' è il limite rappresentato da una della 'following variables'.

Segue un elenco di antipattern, introdotti con una breve descrizione, tutto buoni consigli che se non conosciuti
non fanno suonare alcun campanello di allarme durante lo sviluppo.
Brevemente:

il male necessario: i db connection pool. L'ideale è avere un numero di thread pari al numero di risorse. Spesso infatti i thread vengono bloccati all'infinito in attesa della risorsa libera, in tal caso è da considerare il caso di un timeout. I Resource pool servono per eliminare il tempo di setup delle connessioni. Devono essere dimensionati.

in caso di jsp , esse vengono compilate e vanno nella parte di memoria chiamata JVM permanent generation. Se però si disabilita il garbage collector per le classi ( - noclassgc) tale area di memoria può venire saturata.

ajax: la risposta del servizio richiesto deve essere la più snella possibile; quindi meglio json di xml, evitare html and so on. Quando si usa ajax è facile che aumenti il numero di connessioni, in tal caso configurare il web server opportunamente ( parametri maxclient etc...)

sql: evitare di scrivere query complesse a mano in un sistema che ha un orm ; non tanto perchè l'sql generato da un orm è perfetto ma per lo meno ha sempre la stessa struttura. Evitare join su colonne senza index e evitare di trovare con una query un singolo oggetto e ripetere la query ma usare l'sql per tornare collezioni! Carinissimo il test del DBA: se si mette a ridere guardando le nostre query non si va in produzione.

db: valutare gli index, quando sono da mettere e se sono obsoleti, la partizione di tabelle

rmi: si afferma che è falsa l'idea secondo la quale c'è trasparenza tra chiamate locali e remote. Quando si effettuano chiamate remote meglio evitare di fare molte chiamate all'interno di una singola interazione.

cookie: usarli solo per storare l'informazione circa l'identificazione dell'utente.

...dopo l'elenco di antipattern quello dei pattern:

Pool connection: da usare perchè elimina il tempo di set up di una connessione.

Uso accurato della cache:

- devono avere una dimensione massima di memoria allocabile altrimenti crescendo troppo fanno sì che il
garbage collector sia sempre impegnato nella ricerca di memoria libera
- misurare l'hit rate perchè se è molto basso non ha senso usare una cache
- evitare di mettere in cache oggetti la cui generazione è molto rapida
- usare le SoftReference per mantenere un riferimento agli oggetti per aiutare il garbage collector
- ogni cache deve avere un meccanismo di rimozione oggetti quando i dati sorgente cambiano: ogni cache
deve essere svuotata prima o poi

Precompute Content. Esempio delle categorie merceologiche di un sito di commercio elettronico, il cui elenco cambia di rado e che quindi non avrebbero bisogno di essere generate dinamicamente ad ogni page request. Meglio crere un meccanismo di generazione di frammenti html da includere, così come fa Slashdot. Se esistono politiche di personalizzazione dei contenuti per utente non ha senso.

monitorare il garbage collector ( passando come argomento -verbosegc in java)

[Unix] comandi utili per generazione di metriche

2007-06-07T16:06:00.001+02:00

Come esercizio ho provato a riscrivere uno script ruby usato per la generazione di metriche sul codice in script per la bash shell.

Lo script prevedeva i seguenti macro passi:

1) estrazioni di progetti da cvs

cvs -d :pserver:anonymous:@blablabla checkout progetto

2) recuperare tutte le classi del codice applicativo, ecludendo quindi i test

find . -name "*.java" | grep -v "/test/" > filelist.txt
Nota l'uso di grep -v per ESCLUDERE dall'output tutti i file che stanno sotto una qualsiasi dir con nome 'test'

3) su queste richiamare script di generazione metriche, quale, ad esempio, http://www.kclee.de/clemens/java/javancss/ :

java -cp ~/javancss/ccl.jar:~/javancss/javancss.jar:~/javancss/jhbasic.jar -jar ~/javancss/javancss.jar -all `cat filelist.txt` | grep "Average Function CCN:" | awk -F":" '{print $2}' | tr -d ' ' > ccn.txt

Nota l'uso di awk per considerare solo il numerello al netto degli spazi (pipe con tr)

4) altri script possono generare dell'xml , quindi per recuperare i dati, si può fare:

cat risultatoMetriche.xml | grep ' \ <> ' > metricasottoesame.txt

5) Su questi risultati, definiti per ogni classe, eseguire operazioni come ad esempio delle medie:

expr `awk 'BEGIN {sum=0} ; {sum = sum + $1} ; END {print sum }' metricasottoesame.txt` / `wc -l metricasottoesame.txt | awk '{print $1}'`

[Libri] Recensione libro Release It! parte 3

2007-06-06T11:06:00.000+02:00

Stability Pattern

Scopo di questi pattern non è prevenire che succedano eventi negativi, ma minimizzarne gli effetti.

Use Timeout

L'uso di un timeout definisce un isolamento da una situazione erronea: non si permette ad un problema presente in un sottosistema
di propagarsi nel proprio. Si applica sempre negli integration point.
Il classico esempio riguarda il recupero di una connessione db da un pool, l'esecuzione di una query, trasformare
il resultSet in oggetti e restituire la connessione. In tale ciclo ci possono essere diversi punti in cui si attende una risorsa.
In tal caso può essere sensato inserire timeout in un oggetto che si occupa di far tutto questo , un QueryObject.
Il rovescio della medaglia dell'uso di timeout è il rapido retry. Quindi meglio tornare un risultato (positivo, negativo o
informare che la richiesta verrà esaudita) piuttosto che fornire una risposta lenta.

Circuit Breaker

Il pattern che mi ha colpito di più! Si tratta di un componente che controlla la disponibilità di una risorsa e può
assumere in ogni istante un solo stato tra:
* CHIUSO - permette l'esecuzione di operazioni come sempre. Se l'esecuzione fallisce il circuit breaker lo rimembra. Dopo
un certo numero di fallimenti, superata una soglia entra in stato
* APERTO - tutte le chiamate falliscono immediatamente: non c'è quindi alcun tentativo di esecuzione reale. E' meglio
distinguere il fallimento dovuto allo stato aperto del circuito dal fallimento dell'esecuzione avvenuto quando il circuito
è chiuso. Dopo un certo lasso di tempo in cui ci si augura che la risorsa sia di nuovo up&running entra in stato
* SEMI APERTO - in cui esegue la prima operazione. Se ha successo, ridiventa chiuso, altrimenti ritorna ad essere aperto.
Il circuit breaker può mantenere informazioni circa diversi tipi di fallimento. I cambiamenti di stato dovrebbero essere
sempre loggati e lo stato corrente dovrebbe sempre essere visibile, riportato, misurato.

Bulkheads

Metafora dei compartimenti stagni di una nave. Se un servizio ha due clienti e uno dei clienti è in una situazione
dannosa (si pensi ad un carico eccezionale di richieste) tutto il resto del sistema ne soffre. Ad esempio conviene
sempre mantenere un pool di riserva per le richieste che provengono dall'amministratore del sistema.
Qui il discorso si fa più fumoso. Il concetto rimane chiaro, ma non si intuisce bene come applicarlo.

Steady State

Minimizzare il numero di interventi sulla macchina di produzione: ognuno di essi è rischioso, dannoso.
Così si è pensato quali sono i casi in cui si accede. Uno di questi è la necessità di fare pulizia di dati, quali i log o
vecchi dati nel db. Quando infatti tali dati crescono sempre a dismisura, se non ci sono agenti di pulizia, prima o poi
si generano problemi. Tale pulizia deve essere implmementata nella logica applicativa, altrimenti può essere effettuata
da chi non sa che reazioni possono accadere (script creati da dba)
Tipicamente si esegue la prima release consci del problema delegandolo al futuro, senza poi
affrontarlo. Nel caso di log, prevedere rotazioni temporali e mantenerli in una macchina diversa da quella di produzione.
Un altro caso è l'uso di cache, dove il numero di chiavi può essere infinito, e quindi è opportuno definire un limite.
Serve inoltre una qualsiasi politica di invalidazione ad esempio time based o LRU etc..

Fail Fast

Se il sistema può determinare rapidamente se fallirà l'esecuzione di una operazione è opportuno fallisca
rapidamente. Un esempio di violazione si ha quando un load balancer accetta una richiesta ma sa che al momento
nessun server è attivo eppure la tiene in coda per un po' di tempo. La metafora è quella di un libro di cucina,
dove la precondizione per la preparazione di una ricetta è che ci siano tutti gli ingredienti richiesti.
Un esempio è quando si esegue la validazione dei campi di input dopo aver allocato una connessione: non
si dovrebbe far lavoro inutilmente. Quando si fallisce subito è opportuno notificare al client che è avvenuta
una system failure, ad esempio una risorsa non disponibile, distinguendola da una generica application failure.

Handshaking

Si tratta di implementare una comunicazione tra client e server. In alcuni protocolli di tipo application-level
come l'http non supportano l'handshaking. Può essere utile implementarne una versione custom quando
il costo legato alla necessità di eseguire una chiamata in più (quella per sapere lo stato) è minore di quello relativo
all'effettuare una chiamata che non avrà successo.
Ad esempio, via http, fornendo una pagina che pubblica lo stato del server. Se il cliente tramite questa comunicazione verifica
che il server non può rispondere evita di fare altre richieste (health-check).

Test Harness

(definizione: In software testing, a test harness or automated test framework is a collection of software and test data
configured to test a program unit by running it under varying conditions and monitor its behavior and outputs.)
I test di integrazione verificano il corretto funzionamento del sistema quando tutte le sue dipendenze funzionano correttamente.
Inoltre essi testano casi d'errore coperti da specifiche.
Si possono invece eseguire test di sistema che non verificano le specifiche, ad esempio impostando delle porte in modo
che rispondano con diversi comportamenti:
* una porta che accetta connessioni ma non risponde mai
* una che accetta connessinoi e risponde valori a caso
* accetta una connessione poi la chiude
* risponde molto lentamente
* risponde molto velocemente
Differisce dal mock object in questo senso: i mock object simulano un comportamento che aderisce alle interfacce definite.
Un test harnesses è eseguito su un diverso server e non si conforma alle interfacce; può provocare errori network, di protocollo
o anche a application-level.

[Libri] Recensione libro Release It! parte 2

2007-05-29T17:19:00.000+02:00

Thread bloccati

Situazioni del genere, che accadono quando vari thread cercano di accedere concorrentemente ad una risorsa esterna,
spesso sono difficili sia da testare che da valutare in fase di sviluppo. La soluzione è adottare un buon stile di
programmazione, ad esempio usando librerie solide (in java 5 ad esempio la java.util.concurrent).
Ci sono molte librerie disponibili; il consiglio è di dubitarne, scrivendo test il cui scopo è proprio quello
di romperle.
Un decisivo smell nel design è rappresentato da metodi sincronizzate negli oggetti di dominio.
In tal caso è opportuno rivedere il design. Il primo effetto negativo è dato dal fatto che se l'applicazione
gira su più server è inutile l'integrità dei dati su una sola istanza se l'altra può comunque modificare i dati.
L'altro effetto è del tutto legato alle performance e alla possibilità di essere scalabili: thread che richiedono
oggetti di dominio non dovrebbero mai bloccarsi vicendevolmente.
Di nuovo viene citata l'esigenza di avere dei timeout (quindi basta chiamate java del tipo wait() ).

Davvero illuminante l'esempio di violazione di LSP nel caso in cui in java un metodo di una sottoclasse
è definito sincronizzato mentre lo stesso metodo della superclasse o dell'interfaccia non lo è.
E' una violazione perchè ogni proprietà valida per un oggetto di classe T deve essere valida (no side effect)
su tutte le sottoclassi di T.

Self Denial Attack

Tipicamente quando il reparto marketing organizza una offerta speciale mandando mail con un link
che punta alla pagina dell'offerta. Evitare in quei casi hard link ma far approdare a pagine intermedie.

Point-to-point communication

La comunicazione di questo tipo funziona solo se si hanno uno o due application server che comunicano tra loro.
Se tutte le istanze devono comunicare una con l'altra il numero totale di connessioni cresce come
il quadrato del numero di istanze. In tal caso è opportuno usare altre forme di comunicazione.

Slow Response

E' da valutare quando notificare all'utente di 'riprovare più tardi' ; questo perchè per i siti
la slow response si autoalimenta. Può essere causa di mancanza di memoria ma se si verifica la alimenta anche.
Sla inversion

SLA = Service-level agreement , contratti in cui si definiscono misurazioni relative ai servizi software
consegnati da garantire. In caso di fallimento sono previste penalità. Ad esempio la quantità di tempo
in cui un sito può non essere up&running oppure i tempi di risposta etc..
Un servizio può essere di per sè adatto a rispettare lo SLA definito ma deve considerare la SLA dei
servizi presso cui si interfaccia.

Unbounded Result Set

Bisogna pensare che ogni query può potenzialmente catturare milioni di record. Può essere controintuitivo questa
affermazione in certe circostanze, eppure talvolta la popolazione dei record può essere effettuata
da terze parti il cui comportamento può generare tali situazioni.E' quindi opportuno
che il client definisca quanti risultati può accettare.

[Libri] Recensione libro Release It! parte 1

2007-05-24T17:51:00.000+02:00

La lettura è spassosa, leggera (c'è anche un accenno a Dungeons&Dragons!)
Affronta un tema che finora ho sempre sentito sottovalutato
dal team in cui lavoro, ovvero i problemi di deploy / integrazione tra sistemi.
Spesso infatti noto una grande attenzione alle problematiche di design, di test, di refactoring, di processo,
di stima etc... ma su questo punto si sorvola.
Ogni aspetto legato al deploy, quello architetturale, di security, di logging, di recovery plan etc.
non verrà mai richiesto esplicitamente da un cliente. Un esempio classico è un sistema con un front end
web-based di cui non si sa nulla circa il numero di connessioni che può gestire senza subire effetti collaterali.

Parte 1: Stabilità
Un carinissimo esempio catastrofico, causato da una eccezione Java non catturata.
La morale è che i bachi esistono (pure laddove si usa tdd :)) e sono imprevedibili :
"Bugs will happen. They cannot be eliminated, so they must be survived instead."
I loro effetti possono essere ridimensionati con opportune tecniche
o l'adozione di certi pattern: "A better question to ask is, "How do we
prevent bugs in one system from affecting everything else?" [...]
They cannot—must not—allow bugs to cause a chain of failures."

Una classica obiezione circa l'implementare pattern di stabilità è l'eventuale costo. Il ragionamento
usato per rispondere è ben formulato e conclude con una frase molto condivisibile:
"Good stability does not necessarily cost a lot. [...]
The amazing thing is that the highly stable design usually costs the
same to implement as the unstable one."
Segue della nomenclatura, forse la parte più interessante è la distinzione tra impulso - un evento intenso
e puntuale - e stress - una forza appliccata al sistema che dura nel tempo.

Problemi quando ci sono delle socket.

Dopo una rapida spiegazione del three way handshake si arriva al punto : problemi di grande latenza
nella lettura/ scrittura di dati. Il messaggio è di impostare sempre un timeout differente da quello
di default impostato dal sistema operativo che di solito è dell'ordine di minuti (per quanto riguarda la
scrittura, per la lettura può essere indefinito). Attenzione alla Socket.setSoTimeout() ; prima di usarla
studiare bene cosa fa.

Segue un esempio di un sistema che crollava sempre alla stessa ora, la cui causa si è scoperto essere il firewall.
Ovvero se non c'è trasmissione di dati per molto tempo in una connessione di tipo TCP/IP il firewall
considera gli end point morti, e per lui la connessione non esiste più. Chi legge dalla socket invece
considera la connessione ancora attiva. La soluzione è stata nell'abilitare una funzione di Oracle
chiamata 'dead connection detection' che esegue ping sui client per sapere se la connessione col db
è attiva oppure no. Tale trasmissione di pacchetti ping permette al firewall di considerare la connessione
TCP/IP attiva.

Reazioni a catena.

Si parla di scalabilità orizzontale e verticale. Quella orizzontale indica l'aumento di capacità attraverso
l'aggiunta di server (es: google e amazon), ovvero il concetto di ridondanza. Il difetto è nel sovraccarico
che ogni server attivo deve gestire a fronte di ogni spegimento eccezionale di uno o più server.
Il difetto nel codice che ha generato l'eccezione è presente in ogni singolo application server.
Le reazioni a catena accadono il più delle volte quando ci sono dei thread bloccati; l'applicazione smette
di rispondere e le richieste in ingresso vengono ridestribuite sui server aumentando la probabilità
di fallimento. Un altra causa sono gli outofmemory.

Utenti
:) Qui inizia il paragrafo con la frase "Users are a terrible thing" ; un consiglio è quello di
evitare situazioni di outofmemory, spesso non catturate nei log (es: log4j), mettendo meno informazioni
possibile in sessioni. Ad esempio il risultato di una query al fine della paginazione. Meglio rieseguire
la ricerca ogni volta. In sessione dovrebbero essere salvati dati riutilizzabili.

Mi ha fatto pensare in quali particolari casi può essere utile l'uso di un SoftReference ad un oggetto risorsa.
L'idea è di mettere in sessione un SoftReference all'oggetto in questione al posto del riferimento all'oggetto
diretto. Questo con il vantaggio di rendere disponibile al garbage collector in caso di bisogno l'area
di memoria usata dalla risorsa. Ogni utente in tal modo usa sul server all'incirca la stessa quantità
di memoria. Se però il garbage collector disalloca l'area di memoria referenziata bisogna gestire il caso
in cui l'oggetto viene richiesto da qualche operazione.

In un sistema di ecommerce una parte da testare con riguardo è quella relativa al 'checkout', all'acquisto
di beni. E' un consiglio banale, la parte interessante è legata al fatto che spesso proprio quell'area
è quella che esercita l'integrazione di un gran numero di sistemi (carte di credito, inventario..)
Quindi astraendo la parte più fragile del sistema è quella dove devono collaborare più sottosistemi.
Non conoscevo la definizione di 'conversion rate': la percentuale di visitatori di un sito che acquistano
qualcosa. Se tale conversion rate è di solito del 2 % è opportuno eseguire test di carico di 3-4 volte tanto.

Infine ci sono gli utenti pericolosi, e la mitica DDOS (distributed denial of service).

[Metodo] convincere nell'adozione di TDD

2007-05-14T15:55:00.000+02:00

Cito:

>Uncle Bob! They are asking the business side for "permission" to use an
>engineering Best Practice!

Good catch! No, it's not about convincing the customer to let you act
like professionals. The customer *wants* you to act like
professionals. The customer is *paying* you to act like
professionals. Professionals test their code. Period.

I understand the fear that TDD will slow you down. But it won't.
Just today I taught a group of 16 programmers how to write C# using
TDD. These 16 people worked for three hours straight, getting a small
software application working. Not once in all those 48 man hours did
any of them fire up a debugger. And they got a *lot* of stuff done.
At the end of the session they were all amazed at:

1. How slowly it felt like they were going.
2. How much they got done.

-----
Robert C. Martin (Uncle Bob)

[Metodo] duplicazioni e astrazioni

2007-05-14T14:43:00.000+02:00

Carino un vecchio post sulla ml internazionale dove un tal Wojciech Biela
espone questo problema:
Ho un sistema dove certe informazioni (nome, cognome) provengono da A,
altre (nome, sesso) da B, altre (sesso, eta) da C etc.. come rifattorizzo usando tdd?
Si voleva evitare di creare gerarchie complesse.
Al di là della soluzione, il problema era che non riusciva a eliminare la duplicazione
con una soluzione efficace.
Così Kent Beck risponde che in quei casi può essere utile mantenere la duplicazione
per un po' di tempo, riflettendo continuamente sull'astrazione migliore da adottare.
Cito questa frase:

This process seems a little like science to me. If you don't have enough
data for a good theory, you go get more data, you don't slave away on a
theory that matches the data to date knowing that the next experiment will
destroy your theory.
Kent Beck

[Parole] asbesto

2007-05-11T10:49:00.000+02:00

= amianto.

Citando Piergiuliano Bossi:
" Allora ci vogliono le mutande all'asbesto."

[Film] the dreamers

2007-04-13T22:13:00.000+02:00

Quando penso ad una parigina penso a Isabelle. Folle, artista, debole, magra, viziata, bellissima.
Un tempo incontrai Isabelle; ma poi, come fà il protagonista del film, le strade si sono divise.
L'arte sa essere truce e colpisce solo chi è sensibile alle dipendenze.

[Life] film di fantascienza

2007-04-10T00:22:00.000+02:00

Ho visto " i figli degli uomini " , un film di fantascienza che fa riflettere sull'importanza della vita, della nascita, dei bambini.
La morale è che nei bambini risiede la speranza di un futuro migliore.
Lo consiglio.

http://www.mymovies.it/dizionario/recensione.asp?id=44593

[Parole] travet

2007-04-04T15:57:00.000+02:00

impiegato di basso livello e mal retribuito, che svolge in modo pateticamente scrupoloso il proprio monotono e ingrato lavoro

[Ballo] appunti prima lezione

2007-02-13T00:10:00.000+01:00

VALZER LENTO
piano: partire di sinistro alla battuta 2 per fare il terzo passo, di sinistro, iniziando giro destro aperto.
poi giro sinistro aperto. infine giro destro con spin.
Tanti punti su cui migliorare:
una volta a fianco della dama, mantenere il contatto del punto di equilibrio, senza abbassare la spalla, rivolto col petto verso di lei, abbassando l'anca per permetterle il passaggio. Testa a sinistra, spalle aperte, poi sfilare il sinistro
che va quasi diritto.
Mano sinistra aperta appoggiata in modo che la mano della dama sia aperta e stesa.
Nello spin, chiudere alla prima metà. quinto passo da puntare indietro, col sesto disegni una circonferenza come fosse un compasso che fa perno sul destro. aspettare lei che viene in avanti senza spingerla o affrettare.

TANGO
piano: destro, avanti, chiudo. giro sinistro finito aperto, 8° passo a lato di destro, avanti sinistro e chiudo.
subito medio corté.

mano destra quasi in abbraccio, deve sentire il reggiseno, senza puntare con le dita all'interno della schiena.
nel medio cortè il busto sta sempre fermo, cambia solo la posizione del peso. é aperto sulla sinitra. il gomito destro leggermente abbassato per comodità della dama.
Attenzione che si può andare a ritmo di musica ma in modo stonato se la battuta è sul terzo passo e non sul primo.

[Parole] scampolo

2007-02-05T14:54:00.000+01:00

traccia, rimasuglio, avanzo

[Parole] leguleio

2007-01-13T16:00:00.001+01:00

persona pedante, di mentalità ristretta

[Citazione] nazista del codice

2006-12-13T10:09:00.000+01:00

"Adoro fare diagrammi quando mi aiutano a sterminare codice orrido. Sono un nazista del codice, voglio addirittura l'eugenetica per il codice accoppiato, manco deve nascere, il bastardo."

Piergiuliano Bossi extremeprogramming-it@yahoogroups.com Wed 12/13/2006 5:45 AM

[Parole] spam

2006-12-12T23:21:00.000+01:00

The term was supposedly coined from a Monty Python comedy sketch in the early 1970s, in which every item on a restaurant menu contained SPAM, and there was nothing a customer could do to get a meal without it.

[Fun] pubblicita ikea censurata

2006-11-21T10:58:00.000+01:00

Queste sono pubblicità geniali.
Interessanti.
Simpatiche.
Non volgari.
Censurate.

[Parole] surrettizio

2006-11-10T17:12:00.000+01:00

che occulta intenzionalmente qualche particolare rilevante.

Questa jsp è volutamente surrettizia

[Windows] auto completamento usando TAB da cmd

2006-11-06T09:59:00.000+01:00

If you are an experienced Unix user currently using Windows, you likely miss the command completion feature of the Unix command line interface. To enable this in Windows, simply open up the registry and search for the string completionchar. For each instance of a key with this name, change its value to 9 (the ASCII code of the TAB key). Now you will be able to use the TAB key to complete filenames from the Windows command line interface.

da http://www.diasparsoftware.com/tips-and-tricks.html

[Life] tecniche di presentazione - parte 2

2006-10-29T17:25:00.000+01:00

Gli obiettivi sono , solitamente, i seguenti: informare, intrattenere, ovvero cambiare lo stato emotivo (come zelig), insegnare,
motivare. La vendita e la persuasione sono l'insieme di tutti questi 4 obiettivi.

La programmazione neurolinguistica parte dal presupposto che mente , corpo e linguaggio sono legati da corrispondenze biunivoche.
Ciò significa, ad esempio, che migliorare il proprio stato fisico può portare a migliorare lo stato mentale e così via.
Il linguaggio è quindi influenzato dallo stato emotivo ma può anche influenzare gli altri aspetti.
Un esempio è quando durante un discorso si cambia frase, da "oggi tratterei questo argomento" a "oggi tratto questo argomento". Abbiamo provato a presentare un argomento senza parlare, per osservare la nostra gestualità.
Personalmente ho trovato difficile gestire i miei gesti, ma ne ho preso coscienza: come muovo le mani, come guardo, come mi pongo, sono tutti aspetti che con un costante esercizio si possono controllare.

A livello di contenuti abbiamo esplorato varie tecniche.
La prima è focalizzata sull'uso di un linguaggio variopinto che possa colpire tutti i tipi di persone (VAK).
Ogni persona usa nel proprio linguaggio in prevalenza immagini , suoni o sensazioni.
Le persone visive, ad esempio, "vedono" i concetti nella loro mente, hanno di solito una postura eretta, una
parlata veloce (perchè le immagini da cui traggono il discorso sono più rapide della parola) e usano
spesso parole del tipo: "è chiaro", "vedo bene questa situazione", "si illumina" etc
Le persone auditive -come me- ragionano parlando. Ascoltano con attenzione il loro dialogo interno e ciò che viene loro detto; scelgono con cura ogni parola ed ogni espressione da usare. Parlano lentamente scandendo le parole e modulando tono e tempo di voce. Usano "sentimi", "mi suona bene", "i fatti parlano da sè".
Le persone cinestesiche ragionano in base alle sensazioni che provano, amano il contatto e prestano grande attenzione alle caratteristiche fisiche. Hanno una gestualità lenta e una respirazione addominale (c'è molto contatto con la pancia). "Mi sfugge", "Momenti caldi", "Non riesco ad afferrarlo", "Sono sotto pressione", "immergersi in questa situazione"...

In una presentazione vale quindi la pena di usare esempi che usano tutti i 3 tipi di linguaggio.

L'altra tecnica legata all' efficacia di come presentare un contenuto riguarda i metaprogrammi.
Un metaprogramma relativo all'obiettivo motivazionale è l' "andare verso - allontanarsi da". Alcuni si focalizzano sul futuro e su obiettivi positivi, altri più su ciò che vogliono evitare, tendendo ad analizzare i problemi più che a prospettare risultati.
Un ottimo metaprogramma per costruire metafore è quello del "uguale/diverso" : alcuni si concentrano sugli aspetti che uniscono situazioni/individui, altri su ciò che li differenzia.
"Visione generale o di dettaglio" : alcuni si annoiano di fronte a esposizioni ricche di dettagli, altri le amano.
Utile, ad es. , dare una visione globale per rimandare i dettagli a documentazione o tempi dedicati.

Metaprogramma relativo all'obiettivo di persuasione: si pensi all'acquisto di un vestito.
Alcuni si convincono vedendolo, altri devono sentire che qualcuno fa un complimento, altri considerano la parola scritta (una rivista di moda)
un'autorità convincente, infine altri devono provarlo, agendo fisicamente e provando su sè stessi.
Il contratto degli italiani firmato da Berlusconi è un esempio di sinestesia: ha fatto vedere il contratto, l'ha letto, era una cosa scritta e ha fatto l'azione
di firmarlo.

Sempre nell'ambito della persuasione alcuni si basano sul numero di esempi di successo portati altri sul periodo di tempo (questa azienda è sul mercato da 35 anni).

Gestione delle obiezioni: abbiamo provato a giocare il ruolo di coloro che obiettano antipaticamente ad una presentazione, studiando le strategie adottate.
Bisognerebbe capire il tipo di pubblico, iniziando a collezionare queste informazioni: è un pubblico che è venuto spontaneamente o mandato apposta? E' un
pubblico attivo o passivo? Con un pubblico spontaneo l'oratore ha già un credito, mentre l'altro tipo di pubblico deve essere stuzzicato per prima cosa.
Capito il tipo di pubblico si può usare la strategia del "setting", informando, a inizio presentazione, come reagire: "in qualunque momento
se avete domande fatemi sapere", "siccome le cose migliori sono alla fine fatemi finire" , "purtroppo non avremo tempo di rispondere alle domande" , "le domande solo alla fine"...Dopo aver eseguito setting chi lo viola è in torto: vale lo stesso per l'oratore. Di fatto non si può certo gestire il contenuto dell'obiezione, ma si può agire sul processo. Così, chi obietta quando era stato detto che non si può interrompere fino alla fine è già in torto, e lo si può gestire anche ignorandolo o con una semplice frase (pensavo di essere stato chiaro) per riprendere il controllo del processo.

Concludendo, un grande speaker ha sempre in mente il suo obiettivo, sa stabilire un indicatore per sapere dove si trova nel raggiungimento dell'obiettivo ed è flessibile nella sua esposizione perchè adatta, sulla base del feedback, le sue strategie. Come fa? Conoscendo le varie possibilità a sua disposizione.

Il primo giorno è dedicato al sapere: l'aspetto cognitivo. Quindi: cosa posso fare oltre a concentrarmi sui contenuti, esistono tecniche/emozioni etc..
In secondo giorno è dedicato al saper fare, aggiungendo all'aspetto cognitivo quello fisico.
Il terzo e ultimo è dedicato al saper essere , che ha a che fare con l'aspetto emotivo, ovvero alla relazione esistente tra emozioni e azioni.
Una tesi è quella che sia possibile riaccedere ad uno "stato risorsa" funzionale in qualsiasi momento, perchè la mente confonde tra uno stato mentale e la realtà. L'esercizio è il seguente: pensa ad una emozione che vuoi rivivere. Ad esempio: il relax. Ora rivedi le immagini/ suoni/ sensazioni/ tempo/ volume/ ritmo di qualcosa in cui si è vissuta quella emozione. A questo quadro si possono aggiungere particolari utili a potenziare quella emozione, eliminando invece i particolari che non aiutano. Infine si esegue un gesto (che so, incrociare le dita) per legare l'emozione.

Livelli di pensiero.

La parte più difficile riguarda questo ultimo capitolo. Quando una presentazione ha come scopo quello di portare ad un cambiamento, la sua difficoltà è proporzionale al tipo di cambiamento. Si può voler cambiare, in ordine di difficoltà:
- ambiente ( domande che ci si pone: Dove ? quando? )
- comportamento (che cosa?)
- capacità ( come ? )
e le più difficili:
- valori: ciò che considero giusto e buono ; convinzioni: come rendo concreti i valori (perchè?)
Un esempio è il valore della sicurezza. Uno può convincersi che per essere sicuro si deve isolare; un altro si sente sicuro solo in mezzo alla folla.
- identità ( chi? io sono...) per accedere a questo livello si deve sempre usare una metafora
- livello spirituale (per chi? per che cosa?) cioè la relazione dell'io con l'universo. Un esempio di comunicazione che voleva attivare a questo livello era la pubblicità della telecom che mostrava gandhi in maxi schermo chiedendo: "che mondo sarebbe se...?"

Dopo aver indicato questi punti la riflessione riguarda la congruenza. Se sono una società che richiede di cambiare la capacità di comunicare il messaggio non sarà mai recepito se il cambiamento non si riflette in cascata sui livelli inferiori, ad esempio evitando un ambiente di lavoro a cubicoli.
Un utile esercizio è quello di identificare un obiettivo, percorrere a ritroso tutti i livelli , facendosi le domande indicate per poi attuare un percorso di riallineamento. Una volta catturata l'immagine corrispondente alla sfera spirituale, cosa cambia in tutti i livelli di pensiero a fronte di quella sensazione?

Un aneddoto carino riguarda la madre di un bambino, malato di diabete, che parte alla volta della casa di Gandhi. Arrivata, dopo 2 giorni, chiede al maestro di dire a suo figlio di non mangiare zucchero, altrimenti morirà. Gandhi risponde di ritornare dopo 2 settimane. La donna torna a casa, dopo altri 2 giorni e ritorna dal maestro dopo le due settimane. Alchè Gandhi dice: "ragazzo, non mangiare più zucchero, altrimenti morirari". La donna lo ringrazia, volendo però sapere perchè le ha fatto attendere 2 settimane; non poteva farlo subito? Lui risponde: "due settimane fa anche a me piaceva lo zucchero". La 'morale' è che non sarebbe stato congruente nella sua affermazione, quindi neanche efficace.

Luca Baiguini - Il pubblico nelle tue mani

[Unix] find e find content

2006-10-24T16:11:00.000+02:00

In aggiunta a quanto scritto su
http://dmiessler.com/study/nix/commands/find/

vorrei segnalare due script che stampano i nomi dei file che contengono l'argomento passato i file analizzando il contenuto:

(questo è case insensitive:)
$ cat findContent
grep -H -i "$1" -r ./*

$ cat findContent2
find . -name '*' | xargs grep -l $1

[Life] tecniche di presentazione - parte 1

2006-10-21T18:50:00.000+02:00

Una caratteristica che accomuna la maggior parte delle persone che hanno dovuto presentare un argomento davanti ad un pubblico è stata l'enfasi sul contenuto. Alcuni riferiscono l'inizio della presentazione come una fase tragica perchè scordano cosa dovevano dire. Quindi, riconcentrandosi su quanto preparato, hanno iniziato.

Quanto pesa il contenuto nella buona riuscita di una presentazione ?
Il 7 %, secondo i risultati dell'esperimento di Mehrabian.

La buona riuscita è dovuta, in larga misura, all'aspetto paraverbale (voce, tono, pause – 38 %) e non verbale (gestualità, spazi – 55 %).

Il corso ha esplorato diverse strategie che si possono adottare alternative al 'contenuto' per raggiungere l'obiettivo di una buona presentazione.

Non tutte le strategie sono sempre utili e vengono applicate con disinvoltura da ogni persona. L'importante è entrare in una ottica di sperimentazione: uscire dalla logica 'funziona, non funziona' per entrare in una logica 'quanto mi avvicina all'obiettivo e quanto mi allontata'.

Dopo una breve presentazione di ogni persona abbiamo già notato alcuni punti su cui intervenire:

ansia da inizio: ci si posiziona, si attende qualche secondo prima di iniziare, senza correre, sopratutto senza parlare prima che la platea abbia visto chi ha di fronte (a meno che non sia voluto!)
centratura: un piccolo esperimento ci ha aiutato ad assumere una posizione eretta e sicura. Immaginarsi un pallino del colore preferito sulla sommità del capo. Concentrarsi. Un altro prova a spostarti: ci riesce facilmente! Se si sposta questo pallino sotto l'ombelico ci si trova in uno stato più eretto, meno facile da spostare. Vero!
conclusione: i momenti di maggiore attenzione in una presentazione sono: l'inizio, in cui solitamente viene dato un credito al presentatore. La fine, perchè la platea si desta dal torpore e ascolta le conclusioni. Per ravvivare l'attenzione alla fine bisogna far capire chiaramente quando si sta per concludere. E' sufficiente dire: “per concludere” ..

Odioso dire che si sta concludendo salvo poi non farlo: grave errore!

Ci sono anche altri picchi di attenzione che possono essere ricreati con una operazione detta di 'rottura degli schemi': qualcosa di 'strano' ..una esperienza, un aneddoto, una pausa tragica, una domanda, un cambiamento di tono, uno spostamento da un'altra parte, un gesto non atteso...
motivazione: aiuta auto affermare che 'se sono io , qui, oggi, un motivo ci sarà'. Esempio: un signore ha indicato una bottiglia chiedendo: 'questo è la nostra migliore risorsa?' tutto il pubblico sta per dire: 'sì' poi risponde: 'no, sono loro', indicando omini stilizzati disegnati sulla lavagna.
gesti non gesti / parole non parole: i gesti sono utili nella comunicazione quando usati per rafforzare il contenuto . Esempi: allontanarci , muovendo away le mani, fare nostro, muovendo le mani verso il petto, decidere stringendo il pugno, noi-voi indicando ecc. Altri non sono funzionali. Anche parole come 'praticamente', 'cerchiamo' etc non sono funzionali. Odiosi gli 'eee' , 'mmm' .

Altra presentazione con queste tecniche in mente. Ora notiamo cose positive e negative :

- non sono stata sufficientemente chiara : magari è vero; più che ammetterlo, correggersi.

- non parlare coprendo la lavagna

+scrivere 'di lato' dalla lavagna, avendo cura di guardare il pubblico.

+scrivere bene ;-)

+esperienza personale raccontata con tono diverso, meno mono – tono col resto della presentazione

-dopo vi spiego perchè

-come tutti sapete

-uso di 'ma' e 'però' del tipo: “siete molto in gamba MA dobbiamo chiedervi ...” meglio: “siete molto in gamba e abbiamo l'opportunità di ...”

Abbiamo arricchito la presentazione con l'uso di alcune strategie. Ora non solo il contenuto è importante ma anche il processo.
In particolare, il processo è diventato una competenza consapevole. Applicato sempre più spesso diventerà una competenza inconsapevole, dove spiccherà la nostra personalità senza bisogno di pensare esplicitamente a quali tecniche usare.

Esempio dell'auto: un bambino ha una incompetenza inconsapevole: non sa di non sapere guidare un'auto. Cresciuto, diventa una incompetenza consapevole: ok, si può migliorare, andare a scuola guida. Presa la patente, si è in una fase di competenza consapevole: P attaccato all'auto: so guidare ma penso agli aspetti della guida. Con la ripetizione, diventa una competenza inconsapevole: non devo più pensare esplicitamente ai passi da eseguire. Con lo svantaggio che non mi riosservo più: è facile fermare il processo di miglioramento.

Qual è la causa maggiore dell'abbandono quando si tenta di passare da una competenza inconsapevole a una consapevole? Il sovraccarico di informazioni! In questo momento solo la convinzione e la motivazione ci aiutano.

Riassumendo: in una presentazione contano il contenuto (cosa), il processo (come – da preparare e pensare al pari del contenuto) e: l'obiettivo!

Nei momenti di difficoltà si può sempre tornare su uno di questi aspetti. Gli obiettivi piu comuni di una presentazione sono quelli di informare, intrattenere, motivare, insegnare.

Nella logica del raggiungimento dell'obiettivo entrano le classiche considerazioni, in questo contesto chiamate TOTE (test, operate, test, exit). Qual è la distanza tra la situazione attuale e l'obiettivo? Poi ciclo di applicazioni di strategie, raccolta feedback, metrica per capire se mi sono avvicinato o allontanato finchè non raggiungo. Meglio peggiorare che non andare avanti, per lo meno si ha feedback.

Tecnica utilissima: le ANCORE.

Una ancora è un fenomeno legato ad un altro semanticamente scorrelato. Esempio: una canzone che fa venire in mente una ragazza. Esempio d'uso: il venditore si posiziona a sx del palco imitando una persona triste e senza futuro, soverchiata dai suoi problemi finanziari. Poi su muove a dx, indicando una persona di successo. Tutto deve essere congruente. La persona felice ha una voce chiara, limpida, gesti ampi, aperti. Poi si posiziona in mezzo dicendo: volete essere così o così? indicando i due estremi. Le due posizioni sono ancore, che riportano alla mente ciò che si è settato in precedenza.

Le ancore vanno settate, ripresentandole un paio di volte, spiegando il significato del gesto con chiarezza. Fatto ciò bisogna avere fiducia nelle ancore settate e usarle, senza quindi ribadire il solito concetto.

Altro esempio: un venditore d'auto che chiede : quale marca era l'ultima auto che ha acquistato: A (mettendo le mani a destra) o B (mettendole a sx)? Dopo che ha risposto posiziona i depliant nel posto corrispondente all'auto acquistata nel passato.

Berlusconi che dice: 'c'è una italia libera ecc' avvicinando la mano verso il petto , 'e un'italia dei ladri...' allontanando l'altra mano verso il dietro.

Un informatico che presenta un prodotto. 2 lavagne a dx e sx. Inizia indicando un vantaggio, poi scrive gli svantaggi sull'altra lavagna, quindi, al termine, finisce di elencare i vantaggi. Poi afferma di aver presentato con imparzialità pregi/difetti del prodotto e di attendere la scelta del pubblico. Ha sfruttato i picchi di attenzione: inizio e fine con vantaggi e anche una ancora: alla fine lui parlava nei pressi della lavagna dei vantaggi, che erano l'ultima cosa guardata.

La voce può essere una ancora: lenta e profonda quando si esprimono concetti, rapida quando si elencano informazioni o esempi.

Nota sulle slide:

Lo speaker non deve essere di supporto alle slide ma viceversa. L'attenzione deve essere concentrata sullo speaker, che farà vedere o una mappa del discorso o i dati a seconda del caso. Se il pubblico dedica l'attenzione alle slide, spegnerle.

Anche l'ambiente deve risaltare, con la luce, lo speaker.

[Poesia] passione, debolezza, forza di Tarkovskij

2006-10-19T00:15:00.000+02:00

... che si avverino i loro desideri... che possano crederci,
e che possano ridere delle loro passioni!
Infatti, ciò che chiamiamo passione in realtà non è energia spirituale,
ma solo attrito tra l'animo e il mondo esterno.
E, soprattutto, che possano credere in se stessi,
e che diventino indifesi come bambini:
perché la debolezza è potenza,
e la forza è niente.
Quando l'uomo nasce è debole e duttile,
quando muore è forte e rigido.
Così come l'albero, mentre cresce, è tenero e flessibile,
e quando è duro e secco, muore.
Rigidità e forza sono compagni della morte;
debolezza e flessibilità esprimono la freschezza dell'esistenza.
Ciò che si è irrigidito non vincerà.
( Arsenij Tarkovskij )

[Poesia] Amo gli occhi tuoi, amica mia di Tarkovskij

2006-10-19T00:13:00.000+02:00

Amo gli occhi tuoi, amica mia,
e i loro giochi.
Splendidi di fiamme quando
li alzi all'improvviso e,
come fulmine celeste,
guardi veloce tutt'intorno.
Ma c'è un fascino più forte:
gli occhi tuoi rivolti verso il basso,
negli attimi che un bacio appassionato,
e fra le ciglia semichiuse del desiderio,
il fumo, il fosco fuoco...
( Arsenij Tarkovskij )
(da Stalker di Andrej T. )

[Vita] Termopili e motivazione

2006-10-18T22:21:00.000+02:00

Ho riletto la storia delle Termopili (http://it.wikipedia.org/wiki/Battaglia_delle_Termopili)

Greci motivati hanno combattuto per contrastare l'avanzata dei persiani. I numeri 'storici' sono sconvolgenti: 7000 contro oltre 5 milioni di persiani !
La sconfitta è stata favorita da alcuni traditori.

L'evento è indubbiamente significativo per dimostrare l'efficacia della motivazione.

[Parole] Bordone

2006-10-18T21:54:00.000+02:00

Robusto bastone dalla punta metallica, aveva sulla parte superiore una
ripresa che serviva da appoggio per la mano durante il cammino e sulla
sommità un gancio cui appendere la zucca con l’acqua per il viaggio o la
bisaccia, la punta metallica oltre che avere una presa più solida sul
terreno serviva anche come strumento per difendersi dai briganti.

[Citazione] arte - da "repubblica"

2006-09-04T22:58:00.000+02:00

Quel che riscatta il Diderot de La Religieuse, il Voltaire di Ecrasons l'Infame, Les Fleurs du Mal di Baudelaire o la raffigurazione del sesso femminile di Courbet con il titolo L'Origine du monde, è ancora una volta l'arte, semplicemente l'arte.

[Poesia] Sicilia

2006-08-08T20:11:00.000+02:00

China su foglio bianco.

E' la mia vita. Elegante, ricca di dettagli, priva di una visione d'insieme. Un quadro incomprensibile, prono a molteplici interpretazioni.
Tutte sbagliate: non esiste una chiave. Oppure, esiste! Ma non c'è una serratura da aprire.
La metafora: sei tu.
Che colori le mie labbra di un rosso vivido,vivo, lento e fondente come il magma dell'Etna. La mia pelle diventa nera, attingendo dal colore della tua divisa.
Dirai: "lo era già, pur con le chiaroscure trame che la matita può disegnare".
Eppure tu trasformi le linee in una tinta. Cola il catrame. Dal collo scendendo lungo l'addome.
Copre tutto.

In cielo di giallo, ovvero: di pazzia. Allucinato, ora non sopporto più la pace dell'azzurro. Abbacinato, chiudo gli occhi.
Ora due Soli buissimi coprono il cielo annerendo con luminosità TUTTO. I tuoi occhi.

Ogni oggetto visto con la nuova luce è più piccolo; più minuto.
In sostanza: più misterioso.
Sembra nascondere molto di più di ciò che le leggi della proporzione da secoli sanno spiegare.

Fuggo dal rosso. Mi è negato. Nessun fiore in questo nuovo mondo è diverso dal rosso. Tutto ciò che è nobile, desiderabile (con violenza perfino o con purissimo desiderio) lo è.
E' il rosso dei pomodori che da piccola addentavi come una novella Eva, ebbra nell'assaggiare il frutto del suo peccato.

La furia dei venti muove ogni luogo sfumandone i contorni . Vuoi forse ridisegnarli tu o semplicemente -desideri- confondermi ? Rido, perchè so che nessuna lente potrà mai proteggermi dalla polvere, dalla fuliggine di quell'immensa macchina che incessantemente crea quella fastidiosa Realtà nella quale sto scrivendo - circondato da colori non miei - queste parole blu.

Vorrei intingere l'inchiostro dal tuo cuore, o dal posto in cui le mie emozioni sono generate. Forse la lingua, così vorace e libera. Forse.

[Citazione] Motivation

2006-08-04T13:51:00.000+02:00

Before examining activities or even goals, it is valuable to understand underlying motivation. Motivation leads to goals, which then lead to activities. Motivation acts like a general direction or theme to help guide us in deciding which goals are appropriate.

-----
tratto da http://www.martinfowler.com/articles/itsNotJustStandingUp.html

[Parole] Edutainment

2006-08-02T17:38:00.000+02:00

Edutainment è un termine nato recentemente negli Stati Uniti dalla fusione delle parole educational (educativo) ed entertainment (intrattenimento). Insegnare (comunicare) giocando, potremmo tradurlo un po' liberamente.

[Software Engineers] the best

2006-07-25T13:52:00.000+02:00

Beck

Booch

Fowler

Jacobson

Knuth

Martin

Parnas

Ritchie

Rumbaugh

Thompson

Wirth

[Web Designer] the best

2006-07-13T16:13:00.000+02:00

Zeldman
Tantek Celik
Molly Holzschlag
Jeff Veen
Dave Shea
Doug Bowman
Shaun Inman
Cameron Moll
Joshua Davis
Veerle Peiters
John Oxton

[Citazioni da me stesso] vietare mai sempre

2006-06-08T08:30:00.000+02:00

Io nei rapporti vieterei le parole "sempre" e "mai".

E anche la parola "vietare"

[Parole] feticcio

2006-05-25T16:55:00.000+02:00

cosa o persona fatta oggetto di culto fanatico o di eccessiva stima da gruppi sociali, correnti religiose, artistiche ecc.

[Poesia] la fine è il soggetto

2006-05-23T20:16:00.000+02:00

Vagano. Fuggono. Si nascondono sotto pieghe che non possono essere scoperte dall'ingenuo nè viste dal vigliacco.
Sono come luci lampeggianti di una autoambulanza. Intermittenti. Sfottori. Cinici. Giocosi.
Tutto fanno pur di prendere in giro la parola "voglio". E in loro c'è un sorriso.
Malefico. Benefico. Ai più stolti: indefinibile. Perchè nascondendosi fanno emergere
la crudezza della realtà. Che abbaglia, seria, sul suo trono.
Eppure si muovono con rumore mentre si vestono di ombre. Con voce rauca tentano di suggerirsi l'un
l'altro un "shhhh..".
Qual è il mezzo per scovarvi, per divertirmi con voi ?
Io non ne conosco altri oltre alla follia. Ma la follia è facile, rapida. Tutti l'hanno. Non si tratta
d'altro che darle un volto. Vorrei trovare un altro modo. Non necessariamente più semplice.
Sostanzialmente diverso. Non ho acutezza per udire i vostri suggerimenti nè saggezza per vedere
le briciole che mi lasciate per strada. Altri son giunti a raccoglierle. Prima di me, più veloci. Più nuovi.

Vi ritrovo chiari, numerosi, nudi, nella mia storia. Nel ricordo non avete luoghi dove celarvi. E in fondo vi ho scoperto così: piccoli. Le ombre ora vi danno forza, illusione. Potere. Ma non è sudore delle vostre mani. Quindi siate pure orgogliosi, altezzosi, stronzi. Io so chi siete. Siete nati nei cespugli del mio giardino, sui tabelloni di qualche gioco. Tra i palloni. Nell'attrito tra l'asfalto e la porta s'è formata una scintilla, un calore che ha iniziato la successione. Volate in cielo nei giorni d'estate. Ma non avete ali robuste: vi bagnate nel mare. Con sorriso innocente, fradici, starnutite.
Vi sento ora, mentre scrivo queste parole. Siete attorno a me. Uno, il più impaziente, è appoggiato sulla spalla e spia le parole ancora fresche di inchiostro.
Lascerò qui i miei fogli. Forse domani li avrete fatti sparire. Perché nei momenti delle grandi emozioni voi diventate amici. Mi curate. Mi cullate. Diventate ciò che vi rifiutate di essere: sogni.

[Citazioni da me stesso] ditelo a vostra moglie 2..

2006-05-12T11:44:00.000+02:00

Potrei darti tutto cio' che non mi chiedi