tech

Wiki on a Stick

NicolaCanalini — Wed, 07 Nov 2007 11:39:13 GMT

Da un po' di tempo uso questo wiki per prendere appunti. E' uno strumento utilissimo di cui ormai non posso piu' fare a meno.

Si tratta di un wiki tutto contenuto in un'unica pagina html, no installazione, no configurazione no niente. Lo appiccichi al desktop, doppio click e scrivi.

Testare e' un'arte

NicolaCanalini — Fri, 14 Sep 2007 16:34:20 GMT

Mi piace molto il post di Roy Osherove sulla qualita' dei test. Nel mio team abbiamo iniziato da un po' di tempo a scrivere test e ho proprio visto la nostra suite muoversi da Throw-Away Tests verso Tests that Last.

cancellare pezzi di codice (di test) e' sempre uno sforzo sovrumano per un developer (mio nonno direbbe sovrinumano che e' ancora peggio), la ritengo cmq una pratica indispensabile per portarsi dietro solo quello che veramente serve.

fonte: Throw-Away Tests Vs. Tests that Last

KeyJedi e il PairProgramming

NicolaCanalini — Tue, 29 May 2007 13:02:00 GMT

RoyOvershoe, uno degli agilisti piu' importanti di Israele, ha reso pubblico KeyJedi, una piccola utiliti per visualizzare in tempo reale gli shortcut che vengono utilizzati mentre lavori al pc. Mi sembra un'idea veramente carina e molto utile per il PairProgramming. Quando fai Pair e non hai la tastiera, puoi imparare gli shortcut che usa chi sta scrivendo.

Questo e' il link al post originale da blog di Overshoe.

Strumenti per comunicare

NicolaCanalini — Fri, 25 May 2007 12:57:00 GMT

KatySierra in un bellissimo post sulla comunicazione face-to-face fa una "classifica" dei gingilli tecnologici che possiamo usare per comunicare. L'idea e' di classificarli in funzione di quato si avicinano alla comunicazione face-to-face che lei ritiene, secondo me non a torto, la piu' efficace.

Dallo strumento meno efficace a quello piu' efficace sono:

Email

IM

Twitter

Blog comments

Forums

Chat

Phone

Video chat

Il post intero e' molto interessante, vale la pena di leggerlo.

Testing in a SOA world

NicolaCanalini — Thu, 24 May 2007 16:56:00 GMT

Alcune considerazioni sulle strategie di testing di servizi dal blog di NickMalik.

Dice che SOA porta una serie di cambiamenti nel modo di testare il software. Non mi trova d'accordo, non vedo niente di nuovo ne di speciale in quello che descrive, ha tutto valore anche in un non SOA world.

La strada verso l'acceptance testing

NicolaCanalini — Wed, 23 May 2007 11:53:00 GMT

Yeah a million miles from nowhere
And that's a long long way from home
And that's a long long way from home

Long Way From Home - Stevie Ray Vaughan - Brothers: Family Style - 1990

Nella mia esperienza l'acceptance testing e' un obiettivo difficile da raggiungere che prevede un forte commitment da parte del team di sviluppo e un pesante coinvogimento dell'utente. In questi anni in cui il team in cui lavoro si e' impegnato sul proprio processo di sviluppo non abbiamo fatto passi significativi in questa direzione. Ecco alcune idee che possono servire da sprone per entrare in questo mondo. Credo che il percorso che porta all'adozione delle pratiche di acceptance testing sia dipendente da ogni singola situazione/team, non ho nessuna presunzione di tracciare una strada valida per qualcuno. Solo idee sparse ...

- Installare un tool per l'automatizzazione degli acceptance test e provare a giocarci.

- Scrivere degli smoke test: apri qui, usa il tal utente per fare login schiaccia questo bottone e apri quella form.

- Scrivere la lista delle cose da fare in maniera comprensibile all'utente. Questo aiuta a concentrarsi sulle funzionalita' e su come testarle piuttosto che sulla loro implementazione

- Spezzare le richieste o le storie o come le si voglia chiamare richieste piu' piccole per facilitarne la testabilita'

- Aggiungere alla lista delle cose da fare un campo "How to demo" che descriva in parole semplici come verificare il funzionamento della feature

- Sfruttare i bug come occasione per esercitarsi a scrivere test di accettazione, cioe' ad ogni bug scrivere un test per riprodurlo

La legge del taglione

NicolaCanalini — Mon, 14 May 2007 17:41:00 GMT

occhio per occhio,
dente per dente,
mano per mano,
piede per piede,
bruciatura per bruciatura,
ferita per ferita,
livido per livido

Esodo 21 - Esdra lo scriba - La Torah - IV sec. a.C

E' un comportamento vecchio come Noe' ed e' anche un comportamento psicologico diffusissimo. Se qualcuno piu' o meno intenzionalmente ti da' fastidio, in maniera naturale e piu' o meno coscientemente cercherai di fare un dispetto a questa persona.

Un pattern classico degli ambienti di lavoro e' questo: Arrivi tardi al lavoro, il tuo capo te lo fa notare e ti riprende. Da quel momento devi sforzarti di non guardare l'orologio quando il tuo capo entra in ufficio. Altro caso tipico e' quando sbagli una procedura o una checklist, se te lo fanno notare diventerai il test automatico vivente delle procedure o delle checklist di chi ti ha fatto il cicchetto.

Scambiando l'ordine dei fattori il risultato non cambia. (Questa frase e' chiaramente inutile ma fa sempre un bell'effetto e poi serve per allungare un po' questo post).

Che succede se hai la responsabilita' della sicurezza nei confronti di un gruppo di sviluppatori ?

Secondo me se imponi decisioni di sicurezza crei i presupposti per aprire buchi di sicurezza ancora piu' grandi di quelli che cerchi di tappare. E' opinione condivisa che 100% sicuro sia un'utopia, esagerando (davvero ?) si puo' pensare che intraprendere azioni volte alla sicurezza sia il modo migliore per causare magari involontariamente un incidente.

Penso che con in un team esista un altra strada percorribile. Nel team si deve coltivare la sensibilita' alla sicurezza senza imposizioni esterne. Per farlo e' indispensabile la fiducia. Un altro modo che puo' essere utile e' partire dalla sicurezza del codice. Per un developer il codice e' cosa sacra per cui vale la pena di "spendere" energie.

Digging requirements

NicolaCanalini — Mon, 22 Jan 2007 11:43:00 GMT

Oggi ho viaggiato in treno, ho preso 4 treni di cui uno veramente al volo. dalla piazzola ho visto che il treno iniziava a muoversi quasi impercettibilmente, ho messo il piede sul primo scalino e in effetti ho sentito che il treno stava partendo. Mentre salivo le porte si sono chiuse e hanno tentato di assassinare il mio pc che era nello zaino (n.d.r. il pc e' incolume, lo sto usando per postare).

Trovato un posto a sedere mi sono inventato questa storia che riguarda il sistema di gestione delle porte e il sistema che fa partire il treno.

Storia che riguarda il sistema di gestione delle porte e il sistema che fa partire il treno

In principio c'erano 2 leve, la leva delle porte e quella che fa partire il treno. La prima bloccava la seconda, nel senso che se non chiudevi le porte non c'era verso di far partire il treno. Tra l'altro le due leve erano distanti, qualche progettista disattento aveva messo inspiegabilmente quella delle porte vicino allo specchietto retrovisore e quella per far partire il treno nel centro della carrozza di testa.

Fortunatamente un progettista con tanta cura per l'usabilita' si e' accorto che tutte le volte che si doveva partire si doveva andare allo specchietto, tirare la leva delle porte, tornare al centro della cabina, tirare finalmente la leva per far partire il tutto.

Per qualche migliaio di euro ecco disponibile la nuova leva "faccio tutto in una botta sola". La botta per ora l'ha presa il mio pc.

La conoscenza del dominio di business e' fondamentale per la realizzazione di un software, la cattiva notizia e' che spesso e' qualcosa di estraneo al team di sviluppo, addirittura a volte qualcosa di completamente alieno. La buona notizia e' che si puo' acquisire a piccole dosi o come si dice ... in maniera incrementale.

Raccogliere i requisiti e' un mestiere. E' difficile ed e' uno dei fattori critici di successo di un progetto software indipendentemente dallametodologia di sviluppo adottata.

Un po' di Coraggio

NicolaCanalini — Thu, 30 Nov 2006 11:56:00 GMT

If I told you what it takes
to reach the highest high,
You'd laugh and say "nothing's that simple"
But you've been told many times before
Messiahs pointed to the door
And no one had the guts to leave the temple!

I'm Free - The Who - Tommy - 1969

Il coraggio e' uno dei 4 valori di Xp. Ho fatto fatica a capire il significato del coraggio in un team Xp. Mentre Semplicita', Comunicazione e Feedback hanno implicazioni cosi' forti da saltare immediatamente all'occhio, il coraggio mi sembrava meno decisivo. Ecco cosa penso su questo valore.

Mantenere ben distinte le idee dalla loro implementazione e' un modo per favorire il coraggio.

Puo' essere compito di un coach il separare in momenti di comunicazione differenti l'ideazione dalla concretizzazione; niente uccide di piu' la creativita' dalle difficolta' pratiche.

Per questo motivo secondo me molti musicisti che non sono anche ottimi strumentisti abbandonano lo strumento quando compongono. Molto probabilmente non sanno che stanno riconoscendo la forza dell'idea rispetto allo sforzo della sua implementazione, probabilmente sono guidati dall'istinto.

Possiamo imparare molte cose riguardo all'istinto dalla musica.

Ecco alcuni casi concreti in cui ho riconosciuto il coraggio nella mia esperienza:

- Quando cancello delle linee di codice sorridendo all'idea di commentarle.

- Quando faccio Undo Checkout e ricomincio da capo.

- Quando chiamo il mio cliente e gli dico che "quella storia proprio non riusciamo a consegnarla" e gli chiedo di rivedere assieme il planning.

- Quando alzo il telefono e chiamo il mio cliente per avere delle risposte sapendo che e' preferibile telefonare a satana.

- Quando non ho paura di sbagliare e dico come la vedo io, indipendentemente da chi mi ascolta.

- Quando sento che la soglia del rispetto e' stata superata e mi fermo e non faccio niente.

- Quando ho il coraggio di dire di no. Ma questo merita un post dedicato ...

Rispondo alla domanda di PierG (What are an I-Blog?)

NicolaCanalini — Tue, 28 Nov 2006 16:51:00 GMT

William Gibson in Pattern Recognition descrive un software in grado di indicizzare immagini. In sostanza si tratta di un motor di ricerca che ammette come dato di input un'immagine e cerca corrispondenze all'interno di un database (di immagini appunto). So per certo che esistono gia' funzionalita' di questo tipo esposte per i sistemi cad. Credo che entro il 2010 la textbox sulla homepage di google evolvera'. Accettera in input anche un immagine o un mp3 o un documento ... in sostanza un object. Da li partira' la ricerca sul database mondiale delle cose, cioe' internet.

Microsoft ha un gruppo di lavoro che si dedica a "technology support for everyday memory" (non vi sembra gia' dal titolo una posizione transumanista ?). Tra i giocattoli che stanno preparando c'e' la SenseCam di cui si e' detto molto.

Riverseremo tutta la nostra vita in internet e google o chi per lui la rendera' disponibile.

Ora anche io voglio rispondere alla domanda di PierG che chiede cos'e' un iblog sul blog di Roberdan. Direi che un iblog e' un segnale di quello che sara'. E sai cosa sara' ? sara' che i nostri bimbi si impianteranno un sensore nella cartilagine dell'orecchio che registrera' tutto quello che sentono e lo riversera' in internet. Pensavi di dover avere a che fare con orecchini e tatuaggi ??? Io e te probabilmente dovremo dirgli che non e' bello tenerlo acceso mentre si e' in bagno cosi' come mia mamma mi diceva di tagliarmi i capelli altrimenti nessuno mi avrebbe preso a lavorare.

Dura la vita del papa' nel 2010 ...