Manuel Paccagnella

Come prolungare la vita delle batterie dei laptop

2011-03-28T00:00:00-07:00

Ho da poco acquistato un nuovo portatile e voglio trattarlo bene, facendo durare la batteria il più a lungo possibile. Informandomi in giro ho incontrato molti “boh” e diverse risposte poco convincenti, così mi sono deciso a fare qualche ricerca in proposito (vedi Riferimenti).

Innanzitutto, il famoso effetto memoria (secondo il quale ricaricando ripetutamente la batteria senza arrivare alla capacità massima questa “ricorda” questo livello energetico abbassandone a tutti gli effetti la capacità) riguarda le batterie al nickel-metalidrato (NiMH) e nickel-cadmio (NiCd) che non sono più utilizzate nei portatili moderni. Ad oggi, tutti i dispositivi elettronici dotati di batteria come portatili, videocamere, IPod, etc sono alimentati da batterie aglio ioni di litio (Li-ion) che non soffre di questo problema.

Quando si parla di durata della batteria, due sono i fattori chiave che determinano la durata della vita di una batteria: la temperatura e la carica.

Temperatura

Nel caso delle batterie Li-ion una temperatura troppo altra, specialmente se prolungata nel tempo, accorcia la vita delle batterie. Perciò ecco alcuni suggerimenti da tener presenti:

Assicurati che il dispositivo sia ben areato e non ci sia nulla ad ostruire la ventilazione. In particolare evita di appoggiare il portatile su materiali isolanti come coperte, cuscini e simili che ostacolano la circolazione dell’aria e portano quindi al surriscaldamento.
Evita di ricaricare la batteria mentre stai lavorando: la scheda video, il processore e l’hard disk scaldano e la temperatura diminuisce la vita della batteria.

Carica

Una batteria può essere ricaricata solo un numero limitato di volte, in genere tra le 300-1000 (il numero reale dipende da come la batteria è stata tenuta). Perciò è importante trattarla bene e non ricaricarla troppo spesso.

Qualche suggerimento:

Calibra la batteria ogni 30 cariche. Calibrare significa scaricarla completamente e quindi ricaricarla.
Non scaricarla completamente. Come detto poco sopra le batterie agli ioni di litio non hanno effetto memoria, anzi scaricare completamente una batteria ne accorcia la vita quindi è preferibile limitarsi a farlo solo per la calibrazione. E’ perfettamente sicuro ricaricare la batteria anche se non è completamente scarica, meglio se intorno al 20% della capacità totale.
Evita di caricarla completamente. Le batterie caricate completamente, specialmente se sottoposte ad alte temperature, si deteriorano più in fretta. Di norma è bene non superare l’80% della capacità totale.
Evita lavori intensivi durante la ricarica. Anche scaricare la batteria troppo velocemente ne accorcia la vita.
Evita di ricaricare. Di norma i laptop cercano di ricaricare le batterie al 100% (il che non è un bene), e continuano a ricaricarle non appena scendono al di sotto di un certo livello per mantenerle completamente cariche. Per di più di solito un portatile connesso alla rete elettrica lavora in modalità performace la quale produce più calore.

Conservare la batteria

E’ bene rimuovere la batteria se si lavora prevalentemente connessi alla rete elettrica. Bisogna però considerare che una batteria anche se non connessa continua a perdere lentamente la carica, che invece viene persa più velocemente se viene riposta al 100%. Perciò:

Riporre la batteria ad un livello di carica compreso tra il 40-60%.
Riponila in un posto freddo e asciutto, meglio se intorno ai 0°C. Per esempio in un frigorifero, avvolta in della plastica.
Ricalibra la batteria ogni 30 giorni circa. Ma farla tornare a temperatura ambiente prima di montarla.

In breve

In breve, ecco cosa tenere presente per allungare la vita della propria batteria:

Assicurarsi che il laptop sia ben areato.
Mantenere il livello di carica della batteria tra 20-80% della sua capacità massima, assicurandosi di non effettuare lavori intensivi durante la ricarica.
Calibrare la batteria (ciclo completo di scarica-carica) ogni 30 cariche.
Se si utilizza il portatile prevalentemente connessi alla rete elettrica, rimuovere la batteria e riporla in un posto freddo e asciutto ad una temperatura di 0°C ed un livello di carica tra il 40-60%. Calibrare la batteria ogni 30 giorni.

Riferimenti

Discussione - Adozione dell'Agile

2009-11-09T00:00:00-08:00

Di seguito riporto qualche appunto sull’articolo Why Agile Adoption Fails in Some Organizations apparso su InfoQ il 4 Novembre 2009.

L’agile presuppone che l’organizzazione finanzi il team e che lo sviluppo sia un’attività continuativa e considerata come un investimento. In questo contesto si riconosce l’inevitabile inaccuratezza delle stime iniziali e si procede in modo iterativo e incrementale, accumulando esperienza e imparando a prevedere le tempistiche mano a mano che si avanza con lo sviluppo. In un team agile le stime sulle tempistiche hanno scarsa importanza e il team procede a produrre valore in modo continuativo, ma non si sa con precisione a priori quanto tempo ci vorrà per completarlo.

In uno scenario diverso in cui l’organizzazione finanzia separatamente i singoli progetti, che sono visti come un costo, il management richiede delle stime sui tempi e non è disposto a finanziarlo oltre i tempi preventivati. In questo contesto, a differenza del caso precedente, si hanno dei problemi se la stima iniziale non si rivela corretta e il management è costretto a una scelta:

Modificare i piani e riducendo lo scope del progetto.
Oppure ottenere un ROI negativo (il progetto va in perdita).

Le principali cause del fallimento nell’adozione di uno stile agile di sviluppo possono essere riassunte nei seguenti punti:

L’Agile assume che l’organizzazione voglia uno sforzo di sviluppo continuativo, non un progetto a breve termine. L’agile presuppone un finanziamento a team, non a progetto. In altre parole questo approccio presuppone che non ci siano vincoli di budget sul singolo progetto.
L’Agile è una metodologia che influenza sia il management che il processo di sviluppo: ci sono ripercussioni sia nelle pratiche adottate dal team, sia nella gestione (pianificazione e costi) del progetto stesso. Il management e il processo di sviluppo sono interrelati e qualsiasi metodologia influenza entrambi.

Date queste considerazioni, i progetti a costo fisso sono chiaramente un contesto inadatto nel quale collocare l’Agile. Spesso le aziende che ci provano finiscono per sovrapporre un façade agile su un progetto che in realtà è condotto in stile Waterfall.

In ultima analisi, se l’organizzazione è in grado di finanziare un team di sviluppo in modo continuativo, allora l’agile è un approccio vincente. Se invece i fondi sono allocati per progetto, un approccio più tradizionale è la scelta obbligata.

Discussione

Di seguito riassumo i contributi espressi nei commenti all’articolo da alcuni lettori:

Si assume che un approccio waterfall abbia successo quasi automaticamente in un progetto a costo fisso, quando in realtà è vero l’opposto. Con un cliente che sappia prioritizzare i propri requisiti efficacemente l’agile è un approccio utilizzabile anche in quel caso.
Occorre scegliere la metodologia di sviluppo in base ai requisiti e al contesto: se i requisiti non sono chiari fin dall’inizio e c’è rischio importante che cambino, allora un approccio agile è quasi obbligatorio. Una volta scelto l’approccio più adatto si sceglie la forma contrattuale consona. Le decisioni sulla conduzione del progetto vanno prese in modo pragmatico che rifletta le reali esigenze.

Perhaps we need to start asking, “how much can we get for $X” rather than stating, “I want all this for $Y. Make that happen.” – Robert Dempsey

I metodi agili hanno l’obiettivo di massimizzare l’efficienza, la produttività e il business value realizzato indipendentemente dal budget quindi sono ugualmente applicabili in un progetto a costo fisso. Inoltre, con l’avanzare del progetto e specialmente con l’acquisizione di competenze da parte del team diventa possibile stimare con sempre maggior precisione i tempi richiesti. Ovviamente, in un progetto a costo fisso è ancora più importante avere un team con esperienza e un cliente in grado di prioritizzare le features.

Commenti personali

Innanzitutto l’approccio agile (iterativo e incrementale) comporta importanti vantaggi per tutte le parti coinvolte (clienti, management, sviluppatori), ed è utile educarle tutte sui suoi vantaggi.

Inoltre, data la natura dell’agile (focus su efficienza e qualità) è applicabile anche in un contesto a costo fisso secondo me. Però qualsiasi progetto a costo fisso comporta un rischio sostenibile solo in questi casi:

I requisiti sono chiari fin dall’inizio, sono immutabili e il team è composto da esperti che hanno già affrontato progetti nello stesso dominio applicativo. Solo in questo caso è possibile fare una stima ragionevolmente precisa e adottare un ciclo di vita di tipo sequenziale (Waterfall) con un certo successo.
Lo scope è variabile. In questo caso l’approccio agile continua a essere il più conveniente.

Scelta pragmatica

La scelta della metodologia di sviluppo va fatta in modo pragmatico a seconda del contesto (progetto, dominio applicativo, cliente, team, ecc), non c’è un approccio universalmente migliore (Silver Bullet).

La scelta va fatta anche in base ai parametri che si vuole ottimizzare: costi, tempi, scope e qualità. E’ evidente che il fissare tutti questi parametri a priori è praticamente impossibile, allora occorre trovare la combinazione più conveniente per le parti in causa. Fissando la qualità come un parametro imprescindibile e considerando che costi e tempi sono strettamente connessi, individuo i seguenti casi interessanti:

Tempo	Costo	Scope	Commento
fisso	fisso	fisso	Praticamente impossibile.
fisso	fisso	variabile	Sicurezza sui costi ma scope variabile.
variabile	fisso	fisso	Alto rischio di ROI negativo.
variabile	variabile	fisso	Scenario ideale per l'applicazione dell'Agile.
variabile	variabile	variabile	Efficiente con l'Agile.

Forse dobbiamo cominciare a domandare “quanto posso avere per X$” invece che affermare “voglio tutto questo per X$. Fatelo.” –Robert Dempsey

Alla luce di queste considerazioni, a meno che non si tratti di un progetto a requisiti completamente specificati e immutabili, e condotto da un team esperto nel dominio applicativo, conviene adottare un approccio agile negoziando la forma contrattuale più adatta.

The Agile Coach

2009-11-06T00:00:00-08:00

Attualmente sto lavorando come una sorta di “Agile Coach” all’interno di un’azienda nell’ambito di uno stage, e mi sono ritrovato a studiare molto materiale al riguardo. In questo post ho annotato i punti più importanti dal mio punto di vista leggendo l’articolo The Agile Coach sul numero di Novembre di PragPub.

Il compito dell’ agile coach è quello di aiutare il team a incrementare le proprie performance e ottenere i benefici dei principi dell’agile. Il modo in cui questo viene fatto è guidando il team ad essere più consapevole del proprio workflow e di modi più efficienti di collaborare. Un buon coach deve essere in grado di insegnare come applicare le tecniche agili e di aiutare il team ad acquisirne competenza.
Il coach può essere anche un membro del team, ma le responsabilità nel progetto possono distrarlo dal suo compito (coaching del team). Perciò un coach preferibilmente non ha un ruolo attivo nel progetto a cui lavora il suo team.
Le doti e i requisiti necessari per un agile coach sono:
- Passione per l’Agile.
- Esperienza nell’applicarne le pratiche e i principi.
- Abilità interpersonali: comunicazione, lavoro di squadra, ecc.
- Abilità di problem-solving.
- Pragmaticità.
- Umiltà.
L’approccio di planning conviene rimanga semplice: preferibilmente una lavagna fisica sul posto di lavoro. Per team distribuiti in genere usare fogli di calcolo e wiki è sufficiente, il software di ALM (Agile Lifecycle Management) porta facilmente a piani iper-complicati. Su questo punto non sono molto d’accordo: un buon software è essenzialmente una lavagna virtuale con molte funzionalità aggiuntive che permette di semplificare molto la gestione di un progetto al punto di potersi quasi “dimenticare” del planning. Comunque mi manca esperienza in questo, vedrò.
Avere il cliente spesso a disposizione è di essenziale importanza per il successo del progetto e uno dei compiti del coach è quello di aiutare a costruire una relazione stretta tra il team di sviluppo e il committente creando un senso di impegno condiviso.
Se l’organizzazione non è convinta e non è consapevole di cosa significhi veramente essere agile, conviene cominciare con l’educarla da questo.
E’ importante, come coach, supportare la transizione all’ agile e incoraggiare un atteggiamento di sperimentazione e apprendimento continuo.

Wiki Creole mode for Emacs

2009-11-03T00:00:00-08:00

I needed a syntax highlighting support for the wiki Creole syntax in Emacs, but I couldn’t find it anywhere… until I found the dot.emacs configuration file of Alex Schroeder of emacswiki fame, which contains a little wonderful elisp snippet that I show you (a little bit modified) here:

;; WikiCreole mode (wiki-mode)
;; Thanks to Alex Schroeder of www.emacswiki.org 
;; And Jason Blevins for his inspiring Markdown Mode
;; http://jblevins.org/projects/markdown-mode/
(define-generic-mode 'wiki-mode 
  nil ; comments 
  nil; keywords 
  '(("^\\(= \\)\\(.*?\\)\\($\\| =$\\)" . 'info-title-1)
    ("^\\(== \\)\\(.*?\\)\\($\\| ==$\\)" . 'info-title-2)
    ("^\\(=== \\)\\(.*?\\)\\($\\| ===$\\)" . 'info-title-3)
    ("^\\(====+ \\)\\(.*?\\)\\($\\| ====+$\\)" . 'info-title-4) 
    ("\\[\\[.*?\\]\\]" . 'link)
    ("\\[.*\\]" . 'link)
    ("\\[b\\].*?\\[/b\\]" . 'bold)
    ("\\[i\\].*?\\[/i\\]" . 'italic)
    ("\\*\\*.*?\\*\\*" . 'bold)
    ("\\*.*?\\*" . 'bold)
    ("\\_<//.*?//" . 'italic)
    ("\\_</.*?/" . 'italic)
    ("__.*?__" . 'italic)
    ("_.*?_" . 'underline)
    ("|+=?" . font-lock-string-face)
    ("\\\\\\\\[ \t]+" . font-lock-warning-face)) ; font-lock list
  '(".wiki\\'"); auto-mode-alist
  '((lambda () (require 'info) (require 'goto-addr))); function-list
  "Wiki stuff including Creole Markup and BBCode.")

Just copy this snippet in your .emacs and any file “*.wiki” will be highlighted correctly. You can also enable this mode from within emacs by: M-x wiki-mode.

I’ve adapted it a little bit and stealed some regexps from Jason’s markdown-mode for highligthing titles. But there is still something missing:

Highlighting of lists
Support for images
Better highlithing of external links
Some functions for preview maybe?

Further versions of this mode will be updated here.

Enjoy :)

Come fare una presentazione

2009-11-03T00:00:00-08:00

Con tutta probabilità sei già stato vittima di presentazioni noiose e confusionarie, esposte da esperti in materia che nonostante tutti i tuoi eroici sforzi sono riusciti a farti addormentare…. E questo non è necessariamente dovuto all’oggetto dell’esposizione, infatti persino gli argomenti più noiosi possono essere resi avvincenti e interessanti da un buon speaker.

Fare una presentazione o insegnare in generale è molto di più che essere degli esperti nella materia. Occorrono delle competenze differenti per presentare informazioni in modo corretto: si devono sviluppare le capacità di comunicazione.

“Presentation skills are worthy of extreme obsessive study.” –Tom Peters, Management guru

“Presentation is the ‘Killer Skill’ we take into the real world. It’s almost an unfair advantage.” –The McKinsey Mind

Ottima presentazione = conoscenze + comunicazione

Sommario

Obiettivo delle presentazioni
Sull’uso delle slide
Preparazione: Audience, Tema, Struttura, Pratica, Slide
Delivery: Apertura, Talk (show), Chiusura
Infrangere le regole
Conclusioni
Fonti

Obiettivo delle presentazioni

Prima di imbarcarsi in qualsiasi impresa, occorre conoscerne la ragione. Lo stesso vale per una presentazione:

Qual’è l’obiettivo del talk?
Che cosa voglio che il pubblico apprenda?

Troppo spesso invece si comincia subito a preparare l’esposizione senza alcuna idea di partenza di dove si andrà a parare. Conoscere l’obiettivo di una presentazione è indispensabile per esprimere con efficacia il messaggio principale e per preparare un discorso con un suo filo logico.

Ci sono ben poche cose più noiose di un elenco disordinato di fatti. Una vera presentazione non è un semplice elenco di dati, altrimenti sarebbe più conveniente scrivere un articolo. La ragion d’essere delle presentazioni è il dialogo e l’interpretazione di tali dati. La gente è in grado di leggere, e il motivo per cui si scomoda ad assistere ad un talk è per conoscere il significato e per vedere come questo possa prendere vita. Se ci sono dei dati importanti (grafici, tabelle, fonti, ecc) può essere più conveniente scriverle in un documento apposito e renderlo disponibile agli interessati.

Ma il primo e più importante valore che uno speaker deve tenere sempre a mente è il rispetto: rispetto per l’audiece e per sè stessi. Troppo spesso invece gli speaker dimostrano un’insensibilità totale verso il pubblico, esponendo gli argomenti in modo confuso, incomprensibile e noioso, e subissando gli ascoltatori con aridi e lunghi elenchi puntati nello sforzo di fare bella figura e dimostrare di “sapere”.

The deepest human need is the need to be appreciated. (William James)

E’ essenziale riconoscere al pubblico il rispetto che merita il suo tempo e la sua attenzione, veicolando le informazioni in modo conciso, chiaro e interessante. Si deve essere disposti a sacrificare alcuni dettagli per presentare l’argomento in modo corretto all’audience. E’ questo l’obiettivo di ogni buona presentazione.

The presentation isn’t about you, it’s about your material.

Per avere un’idea di come sono delle presentazione fatte veramente bene:

Vedere su YouTube le presentazioni di: Seth Godin, Tom Peters, Guy Kawasaki, Steve Jobs e Dick Hardt.
Guardare le presentazioni di alcuni dei “maghi” su TED.com, ad esempio: Rives, Hans Rosling, Barnett Thomas, Lawrence Lessig e Ken Robinson.
Se si ha occasione, assistere a qualche talk di Damian Conway.
Vai su Common Craft a dare un’occhiata ai loro tutorial “plain English” sul Web 2.0

Sull’uso delle slide

L’uso di slide (lucidi) è diventato ormai sinonimo di presentazione in molti campi, tanto che la stragrande maggioranza si cimenta nel realizzare questi ausili senza pensarci un istante. Il problema, soprattutto con slide contenenti molto materiale, è che ad un certo punto o la gente legge le slide e non segue più lo speaker (a quel punto converrebbe scrivere un semplice articolo), oppure ascolta lo speaker e non guarda nemmeno le slide (in questo caso non servono neppure).

“Replace Powerpoint with directness and enthusiasm.”

Ripensando all’obiettivo della presentazione e al contesto, occorre invece essere pragmatici e riflettere sull’utilità delle slide: il principale asset e contenuto di un talk è… l’esposizione di un’argomento dal vivo e dalla voce dello speaker. Le slide sono sono un ausilio che può essere utile in alcuni casi. L’esposizione è qualcosa di dinamico, di vivo. Se il pubblico volesse leggere una lista di punti proiettati su uno schermo andrebbe semplicemente a leggersi un libro o un articolo su internet.

PRIMA viene il discorso, DOPO (eventualmente) gli ausili visivi.

Alcuni realizzano delle slide per sentirsi più sicuri durante l’esposizione, ma i lucidi non possono essere un sostituto per la conoscenza dell’argomento che si presenta. O lo si conosce o non lo si conosce. Usare le slide come “stampelle” è la ragione sbagliata per propinarle e una chiara indicazione del bisogno di fare più pratica. Un argomento lo si conosce e lo si comprende veramente solo quando si è in grado di spiegarlo senza alcun ausilio.

Perciò se devi preparare una presentazione, poniti prima questa domanda: posso fare a meno delle slide?

Prima di tutto è necessario avere ben chiaro in mente:

L’obiettivo.
Il messaggio.
L’audience.

L’uso degli strumenti adatti viene di conseguenza.

“Focus on your purpose, your message and your audience and you won’t go far wrong. Once you are clear on those, the details of tools and delivery will become apparent.” –Rowan Manahan

Per un esempio di come è possibile fare una presentazione memorabile senza usare nessuna slide, vedere il talk di Sir Ken Robinson. Inoltre, per un uso creativo e molto visuale delle slide per sottolineare l’esposizione vedere lo stile Takahashi orginale e le sue variazioni che usano anche immagini, come ad esempio la presentazione di Kent Beck sul Responsive Design.

Vediamo ora alcuni suggerimenti su come preparare e effettuare una buona presentazione.

Preparazione

Il suggerimento più importante sulla preparazione di una presentazione è quello di preparala lontano dal PC (e da PowerPoint). Una volta chiaro l’obiettivo, esporre a voce alta in modalità “freestyle” provando vari approcci e annotando idee, frasi e pensieri importanti. Dopo aver steso l’ossatura della presentazione, scriverla su carta (come minimo sotto forma di outline o mappa mentale). Solo dopo si può considerare se servono slide o meno.

Presentazione = discorso

Un passo importante che molti non considerano è che un pezzo scritto prima di raggiungere la sua forma definitiva viene modificato molte volte. Lo stesso vale per i discorsi: per renderli concisi ma evocativi e memorabili è necessario scriverli e perfezionarli esercitandosi molto nell’esposizione. E’ così che i grandi discorsi sono stati creati e hanno potuto esercitare un impatto enorme sulle generazioni a venire: vedi Martin Luther King, Lincoln, Ghandi…

Uno dei più grandi “presentatori” contemporanei, Damian Conway, raccomanda un minimo di 10 ore di preparazione per ogni ora di presentazione (20 se l’argomento è relativamente ostico). Questo ovviamente se si vuole fare un talk memorabile…

E’ anche utile preparare almeno un piano di backup per non essere colti impreparati dalle evenienze.

Inoltre, tenere presente che il modo migliore di illustrare certi concetti è attraverso delle dimostrazioni. Inserirne il più possibile.

Demonstrations beat descriptions.

Audience

Informarsi sull’audience. Quali sono i suoi interessi, lo stato d’animo, i bisogni e le aspettative?
Quanto tempo si ha a disposizione?

E’ importante capire con chi si ha a che fare per veicolare il messaggio nel modo più efficace ed efficiente possibile. Vedere anche un mio precendente post.

Tema

Identificare la singola idea chiave che si vuole comunicare con la presentazione e focalizzarsi su quella. E’ più facile lasciare il segno quando il punto importante è uno piuttosto che una collezione di fatti blandamente correlati.

L’idea centrale costituisce il tema della presentazione. Una volta identificato, raccogliere citazioni, aneddoti, fatti a supporto e organizzarli per costruire una storia attorno ad esso.

Per talk più articolati, possono esserci più idee chiave che si vuole trasmettere, ma è bene non andare mai oltre le 3-5. Avere più di 5 messaggi principali rende difficile seguire il discorso e conservarne qualche memoria.

Struttura

La presentazione deve avere una struttura lineare, semplice, chiara e facile da seguire. Qualunque sia la tipologia dell’esposizione, la sequenza di elementi deve avere una struttura logica coerente.

“Bad storytelling is beginning, muddle, end.” –Philip Larkin

Gli esseri umani amano e trovano più semplice seguire ragionamenti lineari, e tale deve essere la presentazione: una sequenza lineare, logica e concisa di dati, informazioni e aneddoti correlati. Bisogna resistere alla tentazione di farcire il talk di dati per dimostrare la propria conoscenza (ma non il proprio rispetto). Quasi invariabilmente si è spinti a inserire troppo materiale, conviene quindi distillare la presentazione in modo quasi “brutale” eliminando tutto quanto non è essenziale (il tempo è qualcosa di prezioso, non va sprecato).

“La semplicità è la sofisticazione ultima.” –Leonardo Da Vinci

Aiuta avere buone doti di storytelling, ma in ogni caso il talk deve avere un inizio, uno svolgimento (possibilmente che porta ad un climax) e una conclusione che lasci il segno.

Il workflow potrebbe essere:

Identificare i punti rilevanti per l’audience.
Metterli nell’ordine più interessante per il pubblico.
Fornire il contesto necessario.
Arricchire con elementi di teatralità.
Distillare ulteriormente.

La perfezione si raggiunge attraverso la quotidiana diminuzione, non aumento.

Per esempio, per una presentazione incentrata su una soluzione ad un problema:

Illustrare le cause del problema che affligge l’audience.
Mostrare perchè è serio.
Proporre una soluzione.
Sommario e “chiamata alle armi”, riassumendo chiaramente cosa bisogna fare.

E’ molto utile illustrare questa struttura all’inizio della presentazione per dare un’idea di cosa tratterà il talk e come.

Pratica

Una volta costruita la presentazione: fare pratica, pratica e ancora pratica. Preferibilmente ad alta voce. Sperimentare spostando concetti, eliminando quelli superflui e modificando la presentazione in modo che sia ben coesa e comunichi efficacemente l’idea centrale. Possibilmente avendo qualcuno in carne ed ossa che ascolta e fornisce feedback. Inoltre fare attenzione che si rientri nei tempi. E’ molto importante praticare la presentazione, per poi poterla esporre con sicurezza e padronanda davanti al pubblico. Non occorre memorizzare tutto il talk, basta ricordarsi i punti fondamentali, gli accessori verranno con naturalezza se si conosce bene la materia e si è fatta abbastanza pratica.

“The only way to speak better is to speak.” –Damian Conway

La pratica è essenziale, non basta preparare un discorso sulla carta. Come gli speaker esperti e gli attori ben sanno, lo scritto e il parlato sono due veicoli di espressione abbastanza diversi e ciò che è scritto spesso non ha lo stesso effetto quando viene letto ad alta voce. Lo stesso dicasi per l’inverso. Il lavorare al discorso sia in forma scritta che parlata (e praticandolo) permette di chiarire il messaggio essenziale ed “editarlo” in modo da renderlo ad alto impatto.

Slide

Come descritto le slide non sono indispensabili per una presentazione, ma se dopo ever preparato il materiale si decide di utilizzarle, tanto vale renderle memoriabili.

“Great content is a necessary condition, but not a sufficient one.” –Garr Reynolds

Data la facilità disarmante nel realizzarne di irritanti e inutili, il modo migliore per rendere delle slide attraenti è essere consapevole che sono un ausilio, uno strumento il cui compito è quello di sottolineare ed enfatizzare i punti importanti, non di distrarre il pubblico costringendolo a leggere decine e decine di parole. Inquadrare le slide come uno strumento poi, permette di utilizzarle in modo creativo per sorprendere, mantenere l’attenzione e fissare i concetti.

“Nothing in your slide should be superfluous, ever.” –Garr Reynolds

Il criterio più importante da tenere a mente nella realizzazione di slide è: semplicità e stile. Vedere come esempio le slide di: Apple, Bang & Olufsen, The Perl Journal, ecc.

“Your slides, if you choose to use them, should not be textual orgies. Use visual shorthand.” –Chris Brogan

Un grande errore compiuto da molti è quello di pensare alle slide come ad un documento a sè stante: così facendo però realizzano un documento in un formato adatto ad essere presentato su uno schermo, non dei lucidi. Ma semplicemente questo non è l’uso per cui le slide sono state inventate e di certo non è quello migliore nel contesto di una presentazione. Le slide non sono la presentazione, sono solo le illustrazioni.

Le slide NON SONO la presentazione.

In quest’ottica, impiegare poche parole ed eventualmente delle immagini significative. L’uso delle immagini delle slide ha un grande potere: rende possibile coinvolgere il pubblico anche emotivamente e ne stimola l’immaginazione aiutando a mantenere desta l’attenzione e migliorare la memoria di quello che viene detto.

L’approccio risulta ancora più potente se si scelgono immagini significative che rappresentano una metafora (meglio se divertente) dei concetti presentati.

Un’immagine vale più di mille parole.

Inoltre, sorprendere l’audience. E’ un altro modo per creare un’esperienza emozionante che verrà ricordata.

Flusso di informazioni

Se si decide di utilizzare delle slide come ausilio, bisogna controllare il flusso di informazioni in modo che il talk e i lucidi restino in sincrono.

Quando ad esempio si vogliono elencare una serie di punti, il mostrarli tutti contemporaneamente in un’unica slide mentre si parla, significa fare in modo che l’audience li legga tutti e aspetti che vengano trattati cercando di collegare ciò che è scritto a ciò che viene detto. Questo a scapito dell’attenzione. E’ più opportuno in questo caso mostrare un punto alla volta.

Allo stesso modo, se si vuole presentare un grafico, per prima cosa occorre spiegare i dati e il significato prima di mostrarlo nella slide successiva, in modo che a quel punto gli ascoltatori siano in grado di interpretarlo subito. Tra l’altro, il mostrare il grafico dopo averlo spiegato può aiutare anche a creare anticipazione e innalzare l’interesse.

Design

E’ importante che le slide siano leggibili e rispettino delle buone linee guida tipografiche. Se c’è qualcosa di peggio di slide mal realizzate, sono slide mal realizzate e illeggibili. Ecco le linee guida più importanti:

Semplicità e stile!
Attenzione al contrasto: colori complementari. Sfondo chiaro, testo scuro. Sfondo scuro, testo chiaro. Chiaro?
Allineare il testo a destra o a sinistra: l’allineamento centrale è poco professionale, amatoriale e meno leggibile.
Andare all’essenziale: Un titolo, qualche punto e al massimo un’immagine. Avere troppi elementi rende difficile “decodificare” la pagina ed è stressante. La cosa migliore è inserire poche parole con un font di dimensione molto grande.
Usare font della famiglia Serif per il corpo: sono i font che rendono meglio su schermo.
Limitare l’uso di font decorativi ai titoli e solo se sono leggibili.
Evitare di inserire il logo in ogni slide. Non si vuole dare l’impressione di essere dei venditori.
Limitare l’uso di effetti di transizione, possibilmente non usarne nessuno: distraggono e basta. Non essere esibizionista.

Delivery

Presentare qualcosa è più di una semplice recitazione di fatti. Si tratta di una vera e propria esibizione comprendente elementi teatrali e di drammaticità. Bisogna imparare a comunicare con efficacia usando non solo le parole ma anche il linguaggio del corpo, il giusto ritmo, le emozioni, la consapevolezza dell’audience e di come questi elementi li influenzino. Ogni presentazione è una performace finalizzata all’intrattenere il pubblico in modo che al termine ne esca arricchito (possibilmente di quello che si aspettava, meglio se di più).

Entertaining always trumps informative.

Se possibile, arrivare prima dell’inizio del talk e preparare tutto prima che il pubblico giunga in sala. Non è molto professionale armeggiare con il proiettore e il portatile mentre l’audience aspetta… Prepararsi per tempo in modo da essere pronti, sicuri che tutto funziona e (relativamente) rilassati quando arriva l’ora di iniziare.

Una piccola nota: vestirsi in modo consono all’occasione e all’audience. Ovvio, ma meglio precisarlo…

Apertura

E’ normale essere un pò nervosi prima di cominciare un’esposizione. Le cose importanti sono fare molta pratica e iniziare la presentazione con entusiasmo e sicurezza. Ad esempio, per rompere il ghiaccio si può:

Porre una domanda.
Sfidare l’audience.
Citare una persona famosa.
Raccontare una storia divertente.
Raccontare un fatto interessante.
Proporre una visione grandiosa (e poi proporre come farla avverare)
Proporre una visione spaventosa (e poi parlare di come non farla realizzare)

In altre parole basta cominciare il talk con qualcosa di interessante che catturi l’attenzione.

Talk (show)

Di seguito qualche suggerimento su come condurre al meglio la performace:

Muoversi e guardare le persone negli occhi. Usare il linguaggio del corpo per sottolineare certi punti è utile, ma senza esagerare: non è una prestazione sportiva!
Non recitare i punti a memoria o peggio leggere le slide. Bisogna avere rispetto per il tempo degli altri e dato che catturare l’attenzione non è affatto semplice, una volta che la si ha va gestita correttamente. Si deve conoscere bene ciò che si presenta, e questo significa essere in grado di illustrarlo senza che siano necessari ausili esterni.
Usare un tono di voce chiaro, parlare lentamente e variare spesso il ritmo. Bisogna parlare in modo da essere sentiti, chiaramente e ancora una volta portando rispetto verso il pubblico evitando di annoiarlo a morte con un tono di voce costante e noioso (soporiferio). Spesso i novizi durante i talk parlano troppo velocemente: rallentare deliberatamente. - Evitare i “filler”, ovvero cose come: “cioè, uhm, eh” ecc. Denotano insicurezza.
Raccontare una storia. Anche se inventata, è utile per intrattenere e mantenere viva l’attenzione. Ovviamente che sia in qualche modo rilevante all’argomento oggetto della presentazione. Può essere utile anche mischiarla con delle metafore utili ad illustrare certi concetti e relazioni. Inutile dire che l’effetto è migliore se la storia è divertente.
Usare la retorica per essere incisivi e memorabili. Praticare ad esempio con: contrasto, lista dei tre e soprattutto la pausa. Fare una pausa prima di esporre un punto importante crea anticipazione e drammaticità: un momento teatrale che mantiene l’attenzione.
Se ci si dimentica qualcosa, andare avanti con la presentazione senza scusarsi o fermarsi per cercare di ricordare. Se l’esposizione veicola il messaggio principale, allora è ok.
Emozionare. E’ uno dei modi principali e più efficaci per mantenere l’attenzione e far arrivare i concetti a destinazione. Con un pò di pratica diventa facile visto che qualsiasi argomento può essere trattato dal punto di vista umano.
E’ utile anche raccontare aneddoti (soprattutto se personali), umorismo e storie. Un tocco personale può aiutare molto a rendere una presentazione autentica e interessante.
ENTUSIASMO! L’entusiasmo è contagioso. La presentazione deve essere colma di passione, deve prendere vita e catturare l’attenzione del pubblico facendo perdere al tempo il suo significato.
Creare una sensazione di intimità con il pubblico: dare l’impressione di essere lì per loro e di conoscerli trattandoli come amici. L’atmosfera dovrebbe essere rilassata e amichevole.
Eventualmente coinvolgere il pubblico trasformando la presentazione in una discussione interattiva. Invitare a fare commenti e portare contributi personali. Chiaramente è possibile solo per chi conosce veramente quello di cui sta parlando ed è in grado di gestire una discussione, diversamente avrà paura di essere colto in fallo. Comunque tutto dipende dal pubblico e dalla natura dell’argomento: non sempre l’oggetto del talk si presta ad una discussione interattiva e a volte l’audience preferisce non essere chiamata in causa.

“Humans want to connect. They are built to want to belong. A great presentation is a fire to gather around and share an experience.” –Chris Brogan

Per quanto riguarda le domande, è opportuno avere una policy per dove, come e quando accettare domande da condividere con il pubblico. Se non si conosce qualche risposta si può reagire in modo diverso a seconda della situazione:

“Non conosco la risposta mi dispiace.”
Redirigere la domanda a chi può avere la risposta.
“Ora non so risponderti, non appena conoscerò la risposta la scriverò sul mio blog.”

Presentazione memorabile = informazioni + intrattenimento

Chiusura

E’ importante chiudere la presentazione con un sommario che ricapitola i punti principali e un’ultima, chiara ripetizione del messaggio chiave.

“In the beginning, tell the audience what you’re going to tell them. Then tell them, and be sure to leave time at the end to tell them what you told them. It sounds simple, but it works and they will appreciate it.” –Lehr, J.H

Il pubblico deve avere la sensazione di aver ottenuto qualcosa dalla presentazione e deve avere delle informazioni pronte all’uso.

Infrangere le regole

Tutto quello che ho illustrato sono consigli e linee guida, ma tutte le regole possono essere infrante e a volte devono esserlo: le interazioni umane sono qualcosa di troppo complesso e dinamico da poter essere gestito da un insieme di regole ferree seguite senza usare la testa.

Sia un principiante che un esperto possono non rispettarne qualcuna, la differenza sta nella conoscenza: l’esperto conosce le regole che infrange e sa spiegare il perchè lo fa, un principiante semplicemente no.

Per infrangere efficacemente le regole bisogna prima conoscerle.

Conclusioni

Ricapitoliamo i punti importanti:

Un buon discorso è intrattenimento e informazioni. Bisogna imparare a comunicare.
Per fare una buona presentazione è essenziale una estensiva preparazione che va fatta lontano dal PC.
Ogni presentazione deve presentare 1-5 idee chiave e organizzare un discorso lineare, logico e conciso attorno ad esse.
Una presentazione è essenzialmente un discorso, le slide sono un accessorio non necessario. Se vengono realizzare, che siano fatte con semplicità e stile.
Ogni presentazione deve essere un’esibizione colma di entusiasmo e in grado di appassionare l’audience. Imparare ad esibirsi e a creare un’atmosfera intima sono ingredienti fondamentali delle presentazioni memoriabili.
All’inizio anticipare quello di cui si parlerà e alla fine dell’esposizione ricapitolare i messaggi importanti.
Se possibile, dare precedenza alle dimostrazioni piuttosto che alle descrizioni.

Approfondimenti

User Stories Applied, capitolo 2

2009-10-30T00:00:00-07:00

Continua l’esplorazione della tecnica delle user stories.

Per capire meglio che cosa sono le user stories bisogna capire cosa non sono mettendole in contrasto con le altre tecniche di raccolta dei requisiti (use cases, specifiche dei requisiti software IEEE 830 e interactive design scenarios).

IEEE 830

Lo standard IEEE 830 documenta un modo di esprimere le specifiche di un software, principalmente attraverso una gerarchia di requisiti nella forma ”Il sistema dove…”. Un esempio:

4-6) The system shall allow a room to be reserved with a credit card. 4-6-1) The system shall accept Visa, MasterCard and American Express cards. 4-6-2) The system shall charge the credit card the indicated rate for all nights of the stay before the reservation is confirmed. 4-6-3) The system shall give the user a unique confirmation number.

Specifiche a questo livello di dettaglio sono tediose, prone a errori e molto costose in termini di tempo. Per sistemi di media grandezza non sono rari documenti di specifica di 300 pagine… estremamente noiose. la conseguenza è che in realtà gli sviluppatori li guardano appena, ma senza leggerli approfonditamente.
Documenti di questo tipo spingono a pensare ai dettagli implementativi ma rendono molto difficile avere una visione d’insieme.
Non importa quanto impegno si mette nel documentare fin nei minimi particolari le caratteristiche del sistema. Non appena l’utente ha di fronte il software, quasi invariabilmente avrà idee diverse (e migliori).
Le specifiche in questa forma si concentrano sugli attributi del sistema invece che sulle esigenze dell’utente. Si viene spinti a considerare il documento di specifica come una “checklist” delle cose da realizzare, e quindi a dichiarare terminato un progetto quando tutti questi requisiti sono soddisfatti. E quando l’utente modifica le sue richieste, la cosa viene classificata come un cambiamento di scope. In realtà un softwarè veramente terminato quando l’utente è pienamente soddisfatto.

Use cases

In generale uno use case è una descrizione generalizzata dell’interazione tra il sistema e degli attori (che possono essere utenti o altri sistemi).

Uno use case in forma estesa contiene dettagli su un’interazione con in più dei “percorsi alternativi” che costituiscono degli scenari alternativi, in genere per gestire errori. In realtà uno use case esteso è praticamente equivalente ad una storia con i relativi test di accettazione (che prevedono anche i casi alternativi). Ma…
Le principali differenze sono la longevità, la completezza e lo scopo: mentre uno use case rappresenta un accordo tra l’utente e il team di sviluppo fatto per essere valido e normativo (a volte gli use case vengono considerati obblighi contrattuali) per tutta la durata del progetto, una storia rappresenta una conversazione da intrattenere con il cliente e usualmente è utilizzato principalmente ai fini di planning (release, iterazioni).
Gli use case, nella loro forma estesa, sono più soggetti ad essere utilizzati per contenere dettagli sull’interfaccia utente. Il che è chiaramente un male vista la volatilità del design di quest’ultima. Questo è un problema per cui Constantine e Lockwood hanno proposto una soluzione: essential use cases, ovvero una forma di use case ridotta contenente solo: intenzioni dell’utente e responsabilità del sistema, avvicinandoli molto alle storie.
Vista la volatilità dei requisiti software, organizzare un contratto attorno a requisiti a questo livello di dettaglio non fa altro che creare difficoltà: spinge a realizzare il software che l’utente ha chiesto, non quello di cui ha bisogno, infatti l’utente raramente ha le idee chiare fin dall’inizio su quello che vuole.

No matter how much thinking, thinking and thinking we do we can never fully specify a non-trivial system upfront.

Scenari di interazione

Uno scenario è in pratica una “storia” (non nel senso di user story) contenente contesto, attori, obiettivi, azioni ed eventi. Si tratta di una descrizione in forma discorsiva di un’interazione di attori umani in un particolare contesto che hanno determinati obiettivi.

Essendo una descrizione discorsiva e in forma di racconto, molti dettagli sono lasciati fuori percui è comunque necessaria una conversazione con il cliente per chiarirli.
Un singolo scenario ha uno scope decisamente maggiore di una storia, infatti da uno scenario tipico si possono ricavare diverse storie di solito.

User Stories Applied, cap. 1

2009-10-30T00:00:00-07:00

Inizio con questo post una tradizione alla Mark Needham nella quale i annoterò i punti salienti di libri, paper e presentazioni che mi ritroverò a visionare. Questo principalmente per il fatto che il modo migliore per imparare qualcosa (e sapere se lo si è capito realmente) è insegnarlo a qualcun altro.

Per esigenze di lavoro ho cominciato a documentarmi sul project management e alla raccolta di requisiti, principalmente in ambito Agile, e mi sono trovato in contatto con l’idea delle user stories. Il libro che mi sono procurato al riguardo e che sto leggendo attualmente è: “User Stories Applied” di Mike Cohn.

Cominciamo con il primo capitolo, intitolato “Groundwork”.

Ciò che è espresso a parole può essere ambiguo e impreciso. Qualsiasi espressione scritta di requisiti lascerà qualcosa di ambiguo o imprecisato. Basti pensare a frasi come: “Deve essere possibile inserire password di 127 caratteri.” Che cosa vuol dire possono? Significa che in certi casi non è necessario? E devono essere di 127 caratteri? Di più? E di meno? Scendendo sempre più nei particolari non migliora di molto la situazione, ci saranno sempre dei “punti ciechi” e dei particolari mancanti di cui ci si accorge solo durante lo svilupo. L’unica specifica veramente completa in ogni sua parte è il codice sorgente. Ma tutta questa confusione semplicemente scompare se si sposta il focus dallo scrivere i requisiti al parlarne.
Spesso i clienti che richiedono un certo software non hanno le idee chiare e non possono fornire requisiti chiari, stabili e completi fin dall’inizio. Di conseguenza anche se l’analista funzionale è estremamente preciso e diligente nello stilare use case estremamente completi, tutto questo lavoro potrebbe rivelarsi comunque incompleto o semplicemente inesatto rispetto le reali esigenze del committente. Una volta che il cliente ha qualcosa di funzionante sotto gli occhi sarà in posizione migliore di dire ciò di cui ha bisogno. Occorre evitare di fare il classico errore di realizzare ciò che il cliente chiede piuttosto che quello di cui ha bisogno.
Una user story (storia utente) non è altro che una piccola funzionalità che ha valore per l’utente finale. Tradizionalmente scritta su un cartoncino è una semplice frase che indica una funzionalità richiesta dal punto di vista dell’utente (quindi storie come “Deve essere realizzato in Java” non è una storia), dovrebbero essere abbastanza piccole da poter essere implementate nel giro di mezza giornata o pochi giorni da uno o due sviluppatori.
Quando una storia si rivela troppo grande (ad esempio ”L’utente deve poter effettuare una prenotazione”), si definisce Epic e viene suddivisa in due o più storie più piccole.
Una storia, più che definire una funzionalità la rappresenta. Il modo corretto di pensare alle user stories: è come dei “promemoria” di una conversazione da fare con l’utente.
E’ importante capire le aspettative dell’utente per ogni storia: annotare queste aspettative sotto forma di test di accettazione. L’obiettivo è stabilire dei criteri secondo i quali si potrà dichiarare una storia “completa”. Anche qui non si tratta di essere subito precisi e completi, la precisione verrà raggiunta quando sarà il momento.
Secondo la definizione di Ron Jeffries, una storia è costituita da tre aspetti: Card, Conversation e Confirmation. Ovvero, la forma fisica della storia (index card), la conversazione che rappresenta e i test di accettazione per sapere quando è completa.

Behavioural-Driven Development

2009-08-30T00:00:00-07:00

Il Behavioural Driven Development (BDD) è essenzialmente il TDD fatto correttamente. Il problema è che troppo spesso il TDD è portato avanti in maniera scorretta, principalmente a causa dell’eccessivo focus sull’aspetto di testing.

Perchè Behaviour-Driven?

Come illustrato da Dan North, il TDD è un’ottimo stile di sviluppo ma è molto facile fraintenderlo focalizzandosi troppo sui test di unità creando un falso senso di sicurezza:

That’s not to say that testing isn’t intrinsic to TDD – the resulting set of methods is an effective way of ensuring your code works. However, if the methods do not comprehensively describe the behaviour of your system, then they are lulling you into a false sense of security.
–Dan North

Molte delle domande che possono sorgere nella mente di un principiante, ad esempio:

Che cosa devo testare?
Come chiamo questo test?
In che modo posso testare questa caratteristica?

Tutte queste domande, trovano “magicamente” una risposta quando si smette di pensare al testing e ci si focalizza sul comportamento che un sistema deve avere.

Ecco quindi che il BDD si configura prima di tutto come un “re-branding” del TDD (portato avanti tra gli altri da Dave Astels) e un mutamento di prospettiva per far “afferrare” più facilmente il modo corretto di operare con questa metodologia.

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.
–Dan North

Una conseguenza di questo approccio, è che non è più necessario nè raccomandato avere una classe di test per ogni classe di codice di produzione (ad esempio: Queue e QueueTest). Piuttosto di organizzare i “test” per classe interessata, si raggruppano le “specifiche di comportamento” in base alle fixture (o contesti) nei quali si trovano ad operare.

I Vantaggi

Enfatizzare il comportamento sul testing provoca un mutamento nel modo di pensare e produce alcuni vantaggi:

Si parte dai requisiti, dalle features da implementare invece che dalle singole classi. Si adotta quindi un approccio top-down che guida la progettazione in base alle caratteristiche richieste. Come conseguenza si aderisce naturalmente al principio YAGNI.
Si sottolinea l’aspetto di design
Si ottengono delle specifiche che hanno il vantaggio di essere eseguibili, e che quindi possono essere fatte girare contro la base di codice per verificarne l’aderenza ai requisiti fissati (ecco il testing)
Permettono lo sviluppo di un ubiquitous language (ovvero di un linguaggio comune tra gli sviluppatori, la parte business e il cliente), integrandosi con il DDD

Inoltre, seguendo la metodologia BDD si ottengono sia delle specifiche eseguibili (test funzionali e di sistema) sia dei test di unità (applicando la verifica del comportamento alle singole classi).

Strumenti

Trattandosi di TDD “fatto come si deve”, è possibile utilizzare qualsiasi libreria che supporti il testing come l’onnipresente xUnit.

Tuttavia, sono stati sviluppati dei framework che incorporano in concetti del BDD sostituendo ad esempio le parole “test” con “behaviour” o “specification” ad esempio, e fornendo molte altre caratteristiche interessanti come DSL appositamente sviluppati (ad esempio usando groovy in easyb) o interfacce fluide (popolarizzate dal pioniere RSpec), e integrazione di librerie per il mocking come JMock.

Per Java, ho trovato questi framework più o meno utilizzabili:

JBehave2: dal “fondatore” stesso del BDD
Instinct
JDave

Sono tutti costruiti al di sopra di JUnit 4, possono quindi di essere fatti girare in un qualunque IDE (oltre che da CLI o Ant ovviamente).

Esperienza personale

Nel progetto di ingegneria del software a cui ho lavorato abbiamo utilizzato estensivamente l’approccio TDD, rispettando molto il rapporto 1-1 tra classi di test e di codice di produzione.

Non c’è stato molto focus sul comportamento del sistema nel suo insieme, e nemmeno nei test di integrazione e di sistema. Fortunatamente abbiamo fatto uno studio approfondito e un’attenta progettazione durante tutto il processo di sviluppo, facendo attenzione a modularizzare il più possibile (il TDD ha aiutato in questo senso) quindi l’integrazione non è stato un problema molto grave.

Probabilmente però, se fossimo partiti dal principio creando delle specifiche, e usandole per guidare lo sviluppo distribuendo la progettazione lungo il processo e realizzando il prodotto feature-per-feature creando una versione/demo rilasciabile dopo ogni iterazione, sarebbe stato molto meglio.

Update (26/10/2009)

Un paio di articolo di Naresh Jain chiariscono molto bene gli effetti e il significato del BDD:

Automazione!

2009-08-06T00:00:00-07:00

Una cosa risaputa è che un buon programmatore deve essere pigro. Ma di una pigrizia particolare: perchè svolgere a mano ogni compito ripetitivo che può essere svolto altrettanto bene e molto più velocemente da una macchina?

Nella mia situazione, complice anche il fatto che sto imparando Ruby, ho automatizzato diverse cose. In particolare, scrivo su un altro blog di sviluppo personale e per un certo periodo ho avuto un dominio apposito con un blog servito dal software Serendipity che dopo un anno di attività ho chiuso per ritornare a wordpress.

Purtroppo (mea culpa) non avevo effettuato il backup del vecchio blog se non tramite uno “snapshot” del sito, quindi mi sono ritrovato con circa un’ottantina di post sotto forma di file html che volevo importare su wordpress. Inutile dire che farlo a mano sarebbe stata un’impresa non da poco…

Così in un paio di giorni (e un paio di tentativi) ho implementato un programmino di tipo scraper che per ogni post salvato sotto forma di file html, ne estrae: post, titolo, data di pubblicazione e commenti con relative date, nomi ed eventuali link. Il tutto ripulendo il risultato da blocchi non necessari.

Con il primo tentativo ho usato estensivamente le espressioni regolari per identificare ed estrarre le aree desiderate, ma si è rivelato un compito abbastanza lungo e anche se alla fine funzionava per alcuni post c’erano dei problemi. Mi serviva una libreria che fosse a conoscenza dell’html e mi consentisse di farne il parsing.

Con il secondo tentativo, ho utilizzato una stupenda libreria che mi ha permesso di selezionare esattamente i contenuti desiderati e anche di effettuare modifiche: hpricot.

Risultato: una quindicina di minuti circa per postare sul blog originale circa 80 post con la data corretta e tutti i commenti!

Overloading in Ruby

2009-08-01T00:00:00-07:00

A differenza di linguaggi come Java e C++, Ruby non supporta direttamente l’overloading di metodi e costruttori. Il che è abbastanza grave quando si dimostra necessario disporre di più costruttori con un numero diverso di argomenti.

Una soluzione in certi casi potrebbe essere quella di usare un design-pattern come il factory method. In tutti gli altri, fortunatamente, è abbastanza semplice emulare l’overloading grazie al supporto di ruby alle liste di argomenti di lunghezza variabile.

Un esempio, tratto da rubylearning per chiarire il concetto:

# The Rectangle constructor accepts arguments in either  
# of the following forms:  
#   Rectangle.new([x_top, y_left], length, width)  
#   Rectangle.new([x_top, y_left], [x_bottom, y_right])  
class Rectangle
  def initialize(*args)
    if args.size < 2  || args.size > 3  
      # modify this to raise exception, later  
      puts 'This method takes either 2 or 3 arguments'  
    else  
      if args.size == 2  
        puts 'Two arguments'  
      else  
        puts 'Three arguments'  
      end  
    end  
  end
end

Rectangle.new([10, 23], 4, 10)
Rectangle.new([10, 23], [14, 13])

Integrazione Continua

2009-07-27T00:00:00-07:00

Terminato oggi un progetto di dimensioni importanti (con ottimi risultati), è tempo di fare una retrospettiva.

Nel nostro team abbiamo implementato uno stile di sviluppo test-driven, ma non abbiamo predisposto alcun server di build automatizzato. In principio, anche se interessante, sembrava ridondante… Abbiamo ugualmente portato a termine il progetto, ma se avessimo utilizzato una soluzione di questo tipo, avremmo avuto una serie di vantaggi:

Enforcing dell’approccio test-driven: nonostante fosse stato stabilito di scrivere i test prima e per ogni funzionalità, in qualche caso non si è rispettata questa decisione. Probabilmente un sistema che compilasse i sorgenti a ogni commit, che facesse girare tutti i test automaticamente e inviasse un’email a tutti in caso di errori sarebbe stato un aiuto in questo senso.
Pacchettizzazione: come ambiente di sviluppo abbiamo utilizzato Eclipse, che assolve egregiamente i suoi compiti compilando automaticamente i sorgenti ad ogni modifica (segnalando eventuali errori di compilazione) e fornendo un’interfaccia a JUnit per i test. Ma non abbiamo tenuto conto della pacchettizzazione del prodotto finito (“lo faremo alla fine quando sarà ora”). Chiaramente alla fine è stato fatto, ma se avessimo avuto un ciclo di vita evolutivo con un buon numero di piccole iterazioni e un server di build che si sarebbe occupato di creare una versione pacchettizzata pronta per essere distribuita ad ogni commit, la vita sarebbe stata molto più semplice. Se il deployment è continuo, è facile attuarlo. Se non lo è, allora probabilmente ci sono brutte sorprese all’orizzonte…

La lezione è stata imparata.

Update: 09/08/2009

Per approfondire il discorso sull’integrazione continua, è illuminante l’articolo di Martin Fowler.

Ruby - code blocks, coroutines e closures

2009-07-11T00:00:00-07:00

Ruby si ispira abbastanza al Perl (purtroppo, l’ho usato un po’ ma non mi è mai piaciuto come linguaggio), ma nonostante questo mi sono sforzato di andare avanti a studiarlo. Uno è in grado di giudicare le potenzialità di un linguaggio solo conoscendolo e avendolo utilizzato, questo vale specialmente per quei linguaggi che forniscono features che non si conoscono e che richiedono un modo di pensare diverso.

Bisogna respingere la sensazione di “scomodità” che si prova all’inizio ed entrare nell’ottica giusta prima di poterne apprezzare le potenzialità ed esprimere un giudizio informato e non basato unicamente su simpatie/antipatie.

Un linguaggio molto dolce

Ruby, a differenza di Python e similmente al Perl, fornisce una gran quantità di zucchero sintattico che porta ad avere più modi diversi per fare una stessa cosa. Infatti molti “entusiasti” del linguaggio parlano spesso di come imparino sempre nuovi modi più eleganti, concisi ed espressivi per esprimere certi concetti (e questo, almeno nel caso del Perl, spesso a discapito della leggibilità).

Non so ancora se sia una cosa positiva o meno, su questo sospendo il giudizio in attesa di acquisire una conoscenza più approfondita.

Coroutines e code-blocks

Un paio di features interessanti che fornisce Ruby sono le coroutines e i code-blocks, che permettono (tra le altre cose) di implementare in maniera molto concisa ed espressiva degli iteratori e dei “blocchi di codice” da eseguire sotto un controllo transazionale.

In un linguaggio “tradizionale” come Java, per iterare sugli elementi di una classe collezione si può procede ad esempio così:

ArrayList<int> lista = new ArrayList<int>();
// ...
for (int i = 0; i < lista.size(); i++) {
	System.out.println(lista.get(i) + " ");
}

Questo modo di iterare su una collezione è familiare a chi è abituato ad usare linguaggi come C++, Java o anche Python.

Ruby, attraverso l’uso dei code-blocks, permette di iterare in modo diverso:

@lista = [1, 2, 3, 4]
@lista.each {|elemento| puts elemento}

Il che è anche abbastanza leggibile una volta fatta l’abitudine:

	lista: per ogni elemento, scrivilo sulla console

Cosa sono i code block e le coroutines?

Un code-block non è altro che un blocco di codice (incredibilmente), delimitato da parentesi graffe o da do-end che non viene eseguito immediatamente, ma viene messo da parte per essere eseguito in un secondo momento.

Questo code-block deve essere adiacente ad una chiamata a un metodo, la quale può cedere il controllo al code-block ogni volta che lo desidera tramite il costrutto yield tutte le volte che lo desidera, eventualmente passandogli parametri e ricevendone.

A tutti gli effetti il metodo e il code-block sono coroutines, ovvero funzioni che lavorano “insieme” passandosi la palla l’una con l’altra. La cosa interessante è che a un metodo che utilizza un code-block esterno, può essere passato un blocco qualunque di istruzioni. E’ un concetto simile ma più potente e versatile dei puntatori a funzione del C.

Esempio: iteratori

3.times {puts "Hello, world!"}

Questo codice si legge:

	Per 3 volte: stampa la stringa "Hello, world!"

times è la chiamata all’omonimo metodo fornito dal numero 3 (essendo Ruby un linguaggio completamente ad oggetti, è un oggetto di tipo intero) a cui viene associato un code-block che effettua la stampa. Il metodo times non fa altro che richiamare tante volte yield quanto è il valore che rappresenta l’oggetto su cui viene richiamato il metodo.

Si può ottenere lo stesso effetto di prima con una funzione ad-hoc:

def call_block
	for i in 1..3
		yield
	end
end

call_block {puts "Hello, world!"}

Un code-block può ricevere parametri dalla routine da cui viene invocata tramite yield, e similmente riceverne al ritorno, trasformando yield in una vera e propria chiamata al code-block.

Inoltre, passando un parametro al code-block, possiamo implementare un iteratore per una classe collezione (analogo al metodo each del primo esempio) nel modo seguente:

class Collezione
	def initialize(lista)
		@collezione = lista
	end

	def each 
		for i in 0..@collezione.size
			yield(@collezione[i])
		end
	end
end

lista = Collezione.new([1, 2, 3, 4])
lista.each {|elemento| puts elemento}

Questo è più o meno il modo in cui sono implementati gli iteratori nella libreria standard di Ruby.

Diversamente da come illustrato nel design pattern Iterator della GOF, nel quale l’iteratore è una classe esterna all’oggetto su cui itera e di cui mantiene un riferimento, in Ruby un iteratore viene implementato come un semplice metodo all’interno della classe collezione. Questo a quanto pare rende il mantenere questo tipo di codice più semplice.

Esempio: controllo transazionale su file

Quando ci si trova a lavorare con dei file (o comunque con delle risorse esterne), è importante anche rilasciare la risorsa una volta che si è acquisita e si sono effettuate tutte le operazioni necessarie.

Ad esempio, in Ruby è molto facile leggere il contenuto di un file e stamparlo a video:

f = File.open("test_file.txt")
f.each do |line|
	puts line
end
f.close

Anche qui abbiamo usato un code-block (questa volta delimitato da do-end) per iterare sulle linee (delimitate dal carattere newline) contenute nel file.

Il difetto di questo approccio è che se ci si dimendica di invocare il metodo close sul file, questo rimane aperto. Un modo più corretto sarebbe quello di implementare un metodo che apra e chiuda il file, passando il controllo al code-block esterno per processarlo. In questo modo, il metodo che si occupa di aprire il file si occupa anche di chiuderlo:

class File
	def File.open_and_process(*args)
		file = File.open(*args)
		while line = file.gets
			yield line
		end
		file.close
	end
end

File.open_and_process("test_file.txt", "r") {|line| puts line}

Naturalmente non ho considerato le eccezioni in questo esempio.

Il risultato è lo stesso, ma ora abbiamo un controllo sulle transazioni su file. Infatti, questo è il comportamento implementato nel metodo File.open. Se viene fornito un code-block alla chiamata, open restituisce l’handler del file al code-block per farlo processare, e al ritorno chiude il file aperto.

Closures

Un code-block associato ad un metodo può essere memorizzato insieme al contesto dal quale viene passato per essere invocato in un secondo momento. Per fare questo deve essere convertito in un oggetto Proc (abbreviazione di procedure) al cui interno contiene tutte le informazioni sul contesto in cui viene definito (variabili, metodi, costanti, self).

In questo modo, il code-block può essere utilizzato anche quando il contesto in cui è stato definito non è più presente. Un linguaggio che supporta questa funzionalità si dice che fornisce le closures.

Un esempio per illustrare il tutto (tratto dal PickAxe):

def n_times(thing)
  return lambda {|n| thing * n }
end

p1 = n_times(23)
puts p1.call(3)
puts p1.call(4)
p2 = n_times("Hello ")
puts p2.call(3)

La stampa:

	69
	92
	Hello Hello Hello

La funzione lambda converte il code-block in un oggetto di tipo Proc che ritorna al chiamante, con la variabile thing pari al parametro passato alla funzione contenente il code-block stesso. L’oggetto Proc poi, dispone del metodo call per eseguire il code-block memorizzato.

Vediamo qui che, nonostante il parametro thing passato alla lambda sia ormai fuori dallo scope della call, questo è presente perchè memorizzato nell’oggetto Proc.

Ruby - linguaggio interessante

2009-07-10T00:00:00-07:00

Ho una certa conoscenza del linguaggio python, avendolo già utilizzato per dei progetti personali, ma ho deciso di imparare ad utilizzare in modo soddisfacente un buon linguaggio ad alto livello (o di scripting, anche se non mi piace molto il termine).

Data la maggior produttività che linguaggi di questo tipo consentono, possono essere utilizzati per un paio di scopi già da subito:

prototipazione
automazione

Quale linguaggio?

La risposta sembrerebbe triviale: conosco già un pò di Python, quindi sarebbe naturale scegliere di approfondirne la conoscenza, complice anche il rilascio del nuovo Python 3.

Ma sono curioso, e ho sentito molto parlare di questo nuovo linguaggio che arriva dal Sol Levante: Ruby. La killer-application che ne traina la popolarità è senza dubbio Rails e ci sono troppe persone che rispetto e che hanno una grande esperienza che ne parlano molto bene (I Pragmatici, Robert Martin a.k.a “Uncle Bob” e Martin Fowler tra gli altri) per far finta di nulla.

Questo nonostante il parere di Bruce Eckel (di fama “Thinking in [C++|Java]”) che invece ha scelto Python come suo nuovo “linguaggio preferito”. Al di là di confronti feature-a-feature e opinioni sullo stile di design, sono entrambi linguaggi in evoluzione (come dimostrano Python 3 e Ruby 1.9) e che possono essere appetibili a palati diversi, quindi l’unico modo valido per scegliere il “proprio” è sporcarsi le mani.

Conclusione

Credo che darò un’occhiata a questo linguaggio e che nel frattempo lo userò per implementare un pò di automazione in quello che faccio ogni giorno, in ogni caso avrò imparato qualcosa e fatto esperienza.

Assert first!

2009-06-27T00:00:00-07:00

Attualmente sto terminando la lettura del libro “Test-Driven Development By Example” di Kent Beck, ed è in mia modesta opinione una lettura molto istruttiva e utile per chi cerca di imparare questo stile di sviluppo. E’ di grande beneficio vedere la tecnica all’opera e seguirne l’utilizzo passo-passo (forse l’unico modo per sviluppare un feel e assimilarne la mentalità), per poi rifinire la propria comprensione con dei pattern.

Ho già utilizzato questa tecnica per un progetto complesso sviluppato in un team (oltre che altri side-project personali) e quindi ho una seppur minima esperienza in proposito, ma ci sono ancora diverse finezze, tecniche e pattern che posso applicare per migliorare la mia capacità di sviluppare sistemi guidato dai test.

Un’idea nuova che non ho mai utilizzato è quella di scrivere prima gli assert in un test. La motivazione di questo accorgimento deriva dal vedere i test come un modo per guidare lo sviluppo delle funzionalità che un sistema deve avere.

In pratica, un sistema è composto da diverse funzionalità, ognuna delle quali deve essere soggetta a diversi test, ognuno dei quali a sua volta contiene delle asserzioni. La funzione delle asserzioni è molteplice, ma quelle che ci interessano in questa sede sono essenzialmente:

Qual’è la risposta corretta?
Come posso controllarla?

Cominciare a scrivere un test partendo dalle asserzioni (che normalmente in un test completo si collocano alla fine del test-case: test pattern arrange-do-check) fissiamo subito quali sono le funzionalità sotto test, qual’è la loro forma e sintassi e come devono rispondere. A partire da questa conoscenza possiamo costruire il test-case scrivendo tutte le operazioni necessarie per ottenere quel risultato.

Un esempio

(Tratto da: “Test-Driven Development By Example”, Kent Beck)

Supponiamo di voler comunicare con un altro sistema attraverso un socket. Quando abbiamo terminato la comunicazione il socket deve essere chiuso e deve essere stata trasmessa e ricevuta con successo la stringa “abc”.

Cominciamo con le asserzioni:

public void testCompleteTransaction() {
   // ...
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

Il reply viene da un socket:

public void testCompleteTransaction() {
   // ...
   Buffer reply= reader.contents();
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

Il socket lo creiamo connettendoci al server:

public void testCompleteTransaction() {
   // ...
   Socket reader= Socket("localhost", defaultPort());
   Buffer reply= reader.contents();
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

E infine (o in principio) dobbiamo connetterci al server:

public void testCompleteTransaction() {
   Server writer= Server(defaultPort(), "abc");
   Socket reader= Socket("localhost", defaultPort());
   Buffer reply= reader.contents();
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

Campagna per il pensionamento di IE6

2009-06-11T00:00:00-07:00

In questo periodo sto studianto le tecnologie web per un progetto a cui partecipo, e non c’è libro sul CSS in cui mi imbatta che non contenga quasi ad ogni capitolo un riferimento a come qualche versione di Internet Explorer (almeno la versione 6 e precedenti) interpreti erroneamente, o addirittura manchi totalmente del supporto a, molte delle funzionalità richieste per il moderno web.

Si parla di proprietà CSS e anche di bug veri e propri che costringono gli sviluppatori e i designer di siti web a spendere un’incredibile quantità di tempo a sviluppare hacks per costringere IE a renderizzare la pagina correttamente come tutti gli altri browser (moderni o meno).

IE6 è un browser vecchio di otto anni ormai, ma purtroppo una fetta ancora non trascurabile del mercato (i dati parlano di una percentuale di circa il 20% delle connessioni totali), probabilmente perlopiù costituita da utenti business su macchine (ad esempio equipaggiate con windows 2000) che non possono fare un upgrade. E questo è un vero e proprio ostacolo allo sviluppo del web, essenzialmente per due ragioni:

Gli sviluppatori di siti devono spendere molto tempo (circa un terzo del tempo totale) a cercare di aggirare i bug e le mancanze di IE6 quando il sito viene renderizzato già perfettamente da tutti gli altri browser (perchè più rispettosi degli standard). In altre parole sono un bel pò di soldi spesi ad aggirare le mancanze di un browser obsoleto
Gli utenti non possono godere appieno delle nuove potenzialità del web. Provate ad andare su Facebook, o ad usare GMail o 37Signals con IE6…

Ecco perchè è nata una campagna per spingere l’upgrade a browser più moderni (anche ad un’altra versione di IE, solo più recente). Dalla dichiarazione d’intenti della campagna (la traduzione è mia, ora sapete chi incolpare per gli errori):

La premessa è semplice: Internet Explorer 6 è antiquato, non supporta standard web chiave, e dovrebbe essere pensionato. Questo non riguarda l’essere anti-Microsoft, piuttosto riguarda la mancanza di sviluppo del mercato dei browser da parte di Microsoft. Con IE7/8 non disponibili per Windows 2000, IE6 conta circa per un 20% dell’uso del web, principalmente da parte di utenti business. I clienti fanno pressioni sui designer per “contringere” i siti a funzionare con IE6, e i designer, non volendo perdere affari, obbediscono, usando trucchetti e aggirando i problemi. Questa è una perdita di tempo e denaro. Microsoft deve sistemare questa situazione, i designer devono unirsi, e noi dobbiamo passare oltre.

Il dover avere a che fare con sistemi legacy non è una cosa nuova, accade continuamente ed è una conseguenza dell’avere un mercato con una grande inerzia ai cambiamenti. Ma quando questo significa solo uno spreco di soldi e di tempo come in questo caso, evitabile in modo piuttosto semplice, allora occorre spingere per andare avanti e disfarsi di una tecnologia obsoleta.

“IE6 is the new Netscape 4. The hacks needed to support IE6 are increasingly viewed as excess freight. Like Netscape 4 in 2000, IE6 is perceived to be holding back the web.”
–Jeff Zeldman, standards guru

Web Software Engineering?

2009-06-07T00:00:00-07:00

Ultimamente sto facendo pratica con la programmazione orientata al web (come noterai dall’argomento dei post precedenti).

La mia impressione è che mentre per il software tradizionale abbiamo ormai una certa esperienza e conosciamo molti pattern e best-practices da applicare, nel caso della programmazione web non è proprio così.

Ci sono alcune soluzioni e metodologie di sviluppo mutuate dalla controparte stand-alone che possiamo applicare, alcuni principi che rimangono utili (riuso, interoperabilità, estendibilità, ecc.) ma ci sono anche nuove sfide da affrontare e molte cose da scoprire che sono peculiari di questo “ambiente di sviluppo”.

Se l’ingegneria del software è una disciplina giovane, l’applicazione di questa disciplina al web lo è ancora di più. Il web è una piattaforma che consente possibilità non facilmente disponibili per il software desktop: probabilmente siamo solo all’inizio e, secondo la mia attuale ingenua visione, il futuro si rivelerà decisamente interessante :)

Google Wave!

2009-06-07T00:00:00-07:00

C’è molto fermento dietro il fenomeno Google Wave che potrebbe rivoluzionare il modo di comunicare e collaborare online.

Bando alle ciance ed ecco la presentazione ufficiale:

Sarà rilasciato al pubblico nel corso di quest’anno, ma sono già disponibili le API per integrare Wave con le proprie applicazioni e siti web e il sito dedicato al protocollo sottostante.

Si prospettano tempi eccitanti :)

Cos'è AJAX?

2009-06-06T00:00:00-07:00

AJAX è l’acronimo di Asynchronous Javascript And XML e indica una tecnica per permettere di costruire applicazioni web paragonabili a quelle stand-alone che utilizziamo normalmente.

L’utilità di AJAX

Un’applicazione web tradizionale solitamente costruisce una pagina web che invia al client. Questo compie delle azioni (riempie form, clicca dei link, ecc.) che vengono inviate al server come richieste http, il quale le elabora e costruisce una nuova pagina web che ritrasmette al client.

Questo modello funziona, ma ha l’inconveniente di essere sincrono: da quando l’utente invia una richiesta a quando il server risponde con una nuova pagina, l’utente non può far altro che aspettare.

Il meccanismo funziona per un web che è stato pensato per gli ipertesti ma non è più sufficiente per le esigenze moderne di applicativi costruiti sul web stesso. Applicativi che necessitano di essere responsivi.

Alcuni esempi di applicazioni web molto usate costruite con questa tecnica sono: GMail, Google Maps e Google Docs.

Da cosa è costituito

XHTML e CSS: per la presentazione
DOM: per il layout dinamico e l’interazione con la pagina
XML e XSLT: scambio e manipolazione dati
XMLHttpRequest: recupero asincrono dei dati
Javascript: collante per tutte le tecnologie precedenti

Come funziona

AJAX è stato creato per consentire alle applicazioni web un dialogo asincrono tra client e server minimizzando così il tempo di risposta percepito dall’utente.

In pratica si tratta di interporre tra il browser del client e la rete nella quale si trova il server un motore AJAX, che consente all’utente di interagire con l’applicazione web direttamente senza aspettare la risposta del server.

Dialogo client/server asincrono

Per certi compiti come la validazione dell’input e l’elaborazione di alcune informazioni, il motore AJAX può cavarsela da solo. In tutti gli altri casi in cui è richiesta una risposta dal server, è il motore stesso che si occupa del dialogo consentendo all’utente di continuare ad interagire con l’applicazione mentre si è in attesa della risposta.

Il dialogo poi si svolge solitamente attraverso frammenti XML, senza il bisogno di ricaricare (e ritrasmettere attraverso la rete) l’intera pagina.

E’ questo in sostanza che consente al sistema di fornire all’utente un tempo di risposta inferiore, simile a quello di un’applicazione desktop. Qui però la velocità di un applicativo non è più determinata principalmente dalla velocità del sistema, ma dalla velocità della rete.

La maggiore sfida che Ajax pone davanti ai nostri occhi non riguarda la risoluzione dei problemi tecnici da esso derivati, ma il dimenticare tutte le limitazioni che riguardavano il Web, per lanciarsi verso la creazione di applicazioni robuste, veloci e sempre più simili alle applicazioni Desktop.
–Jesse James Garrett, Ajax: a new approach to web applications

Credits

Grazie a Daniele Simonin per la sua traduzione dell’articolo di Jesse James Garrett.

Riflessioni sul cloud computing

2009-06-05T00:00:00-07:00

Ultimamente si fa un gran parlare di Cloud Computing, e di come questo “nuovo” modo di intendere il software come un servizio (SaaS) possa essere conveniente o meno.

I pro

I vantaggi di un modello del genere sono presto detti:

non c’è alcun bisogno di predisporre datacenter
non occorre occuparsi del deployment e della messa in sicurezza
non occorre pagare personale interno che li amministri
tutto il software è direttamente accessibile mediante il browser
i dati sono nella cloud e accessibili (previa autenticazione) da qualunque parte del mondo e da qualunque pc
basta un pc depotenziato come un netbook per accedere a questi servizi (anche computazionalmente intensi)

Quindi i software sono forniti come un servizio, unitamente alla loro gestione per cui un utente non occorre che si preoccupi di altre problematiche aldilà del loro utilizzo. Si tratta di un ulteriore passo verso l’outsourcing.

Esempi di questi servizi sono GMail e Facebook, che sono diventati molto popolari e che hanno aumentato di molto l’efficienza e la produttività (almeno per quanto riguarda GMail).

I contro

Ma se da una parte il cloud computing è molto comodo perchè solleva dalla necessità di installazioni e configurazioni varie, dall’altra fa sorgere un problema di fiducia e di sicurezza in generale, come fa notare Bruce Schneier.

Sicurezza

Mentre posso gestire autonomamente il software installato in locale predisponendo misure di sicurezza come firewall e ambienti di esecuzione controllata, nel caso di SaaS sono completamente in balia del provider di quel software.

Senza contare che se uso un software a codice chiuso e che viene eseguito per di più su macchine remote, non posso essere sicuro che il servizio in questione non faccia di più di quello che dichiara. Di conseguenza sarei portato a fidarmi di più di un servizio basato su software open-source e di standard condivisi.

Privacy

Se utilizzo il cloud computing, utilizzo un software in cui immetto i miei dati che vengono memorizzati in maniera distribuita su server del gestore del servizio. In pratica sto a tutti gli effetti fornendo miei dati a una compagnia esterna che può essere o meno affidabile. Non ho nessun controllo sulle misure di sicurezza di quella compagnia che potrebbe anche avere accesso ai miei dati, o che potrebbe essere compromessa con relativo furto di informazioni.

E se quella compagnia ad esempio va in bancarotta o subisce dei guasti, posso perdere completamente i miei dati.

Inoltre, se i servizi sono accentrati in un’unica piattaforma, un’eventuale compromissione e furto d’identità potrebbero causare danni molto ingenti. Prova a immaginare a un ipotetico servizio che fornisse al tempo stesso email, piattaforma per lo sviluppo di documenti, blog, gruppi di discussione e conversazioni in tempo reale (suona familiare?). Immagina che venga compromesso e che qualche persona senza scrupoli si impadronisca del tuo account. A quel punto avrebbe accesso alle tue email, documenti e contatti e le sue azioni avrebbero una portata enorme sia sulla tua vita lavorativa che personale…

Certo, possono essere adottate misure di sicurezza come crittografia (sia a livello di connessione con https che di storage con AES ad esempio), autenticazione e backup. Ma il punto rimane che il controllo ultimo sulla configurazione e controllo del sistema rimane al fornitore. E i tuoi dati sono in quel sistema.

Lock-in

Quando i dati risiedono su server di terze parti, oltre alle problematiche della sicurezza e della privacy occorre preoccuparsi della portabilità.

Non basta che il fornitore abbia una buona infrastruttura di sicurezza, usi la crittografia, e abbia dei sistemi di backup. Occorre che i dati che io immetto nel sistema li possa recuperare in ogni momento e integralmente, e devo essere sicuro che quando li cancello vengano eliminati realmente (non come nel caso di Facebook).

Si tratta in altre parole di avere il controllo completo sui propri dati, in caso contrario subiamo l’odioso vendor lock-in che stiamo solo ora cominciando a superare nel campo delle suite office e delle pubbliche amministrazioni.

Pay-per-use

Non potendolo classificare come pro o contro, c’è comunque da considerare questo aspetto.

Il cloud computing permette nuovi modelli di business, tra i quali c’è il richiedere un corrispettivo per la fornitura di risorse e software in una cloud. Questo può essere un aspetto positivo per il fornitore e per l’utente (migliore servizio), ma può anche non esserlo, dipende dai punti di vista.

Riflessione

Il cloud computing per come è nato ha proprio gli obiettivi di tagliare i costi di gestione, incrementare la facilità di accesso e la produttività. Però ci sono anche delle problematiche di sicurezza e di fiducia che emergono da questa architettura.

E’ anche vero che si possono avere i vantaggi del Cloud Computing in una intranet, mantenendo il controllo sui propri dati e conservando la comodità della centralizzazione di accesso e utilizzando storage e risorse di calcolo distribuite. Ma al costo di sacrificare l’accesso globale (a meno di non predisporre VPN) e di re-introdurre i costi di gestione di un datacenter.

Bisogna stare attenti di chi fidarsi e per cosa. I meccanismi del mercato dovrebbero spingere i fornitori a erogare un servizio di qualità, ma quello che si guadagna in comodità e risparmio, lo si può perdere in privacy, sicurezza e flessibilità.

Trust is a concept as old as humanity, and the solutions are the same as they have always been. Be careful who you trust, be careful what you trust them with, and be careful how much you trust them. Outsourcing is the future of computing. Eventually we’ll get this right, but you don’t want to be a casualty along the way.
–Bruce Schneier

JDK7 - piattaforma modulare multi-linguaggio

2009-06-04T00:00:00-07:00

Secondo un articolo di InfoWorld, la nuova nuova versione del JDK Sun adotterà un design più modulare che supporterà la versione 7 del linguaggio Java. E questo porterà, secondo Mark Reinhold (ingegnere principale dietro Java SE e OpenJDK) a una serie di vantaggi.

Classpath will be dead

La modularità verrà raggiunta attraverso il progetto Jigsaw, che permetterà agli sviluppatori di sviluppare i propri moduli e di eliminare la necessità del classpath.

“Class path is dead,” Reinhold said.

Un JDK per domarli tutti

La modularizzazione potrebbe portare anche ad una singola versione di Java, dato la capacità di un sistema del genere di adattarsi all’ambiente in cui si trova ad essere eseguito.

Piattaforma multi-linguaggio

“We’re working to define a modular form of the Java platform and its implementation; we’re working to evolve the Java Virtual Machine into a true, multilingual universal runtime for high-level languages; and finally, we’re doing things to make developers more productive,” said Mark Reinhold, principal engineer for Java SE and OpenJDK.

Aspetto per me decisamente più importante. Per come la vedo io, l’uso di un ambiente di esecuzione per codice managed che permetta a programmi scritti in linguaggi diversi di comunicare e cooperare tra loro, in un’ambiente comune e con un set standard di librerie, è una carta vincente.

Già ora esistono soluzioni simili, le più famose delle quali sono il CLR della piattaforma .Net e appunto il JRE che già ora supporta un gran numero di linguaggi anche molto diversi tra loro come Scala, Groovy, Clojure, Jython e JRuby per citarne alcuni.

Crescente uso delle annotazioni

Per facilitare il compito dei checker statici.

Conclusioni

Con queste nuove modifiche la piattaforma Java potrebbe diventare a tutti gli effetti un ambiente di esecuzione in grado di supportare una gran varietà di necessità, linguaggi e stili di sviluppo, il tutto garantendone l’interoperabilità e l’esecuzione controllata.

Tutte caratteristiche che secondo me potrebbero diventare irrinunciabili in molti settori.

L'importanza della pianificazione

2009-06-02T00:00:00-07:00

Proceed from a plan, whether that plan is in your head, on the back of a cocktail napkin, or on a wall-sized printout from a CASE tool.
–“The Pragmatic Programmer”, Andrew Hunt, David Thomas

Iniziare un progetto senza uno straccio di piano è una ricetta per il fallimento, o quantomeno per un’efficientissima fonte di mal di testa.

Non si tratta di pianificare ogni minimo dettaglio fin dal principio. Questo è controproducente (al di là di casi particolari come i programmi che equipaggiano lo space shuttle). Ma non si tratta nemmeno dell’estremo opposto: procedere, praticamente, a caso.

Alcuni proponenti dell’approccio agile erroneamente portano all’estremo il concetto di self-organization, sostenendo in maniera più o meno implicita una generale antipatia per la pianificazione.

Tecnologia

Nell’ambito tecnologico possiamo vedere questa “lotta” ad esempio a livello di progettazione.

Da una parte abbiamo i proponenti del BDUF, che sostengono una specifica completa e dettagliata prima di cominciare a codificare. Il che nella stragrande maggioranza dei casi significa perdere tempo in dettagli minuziosi basati su assunzioni non verificate, per poi scoprire che la soluzione non funziona o che ce ne sono di migliori e più eleganti, a cui non si arriva se non avendo sott’occhio il codice.

Life is what happens to you while you are busy making other plans.
–John Lennon

Dall’altra abbiamo certi “agilisti” (partigiani) che aborriscono qualsiasi forma di pianificazione e preferiscono lanciarsi nella codifica “lasciando che il design si riveli ed evolva da sè grazie ai test”. Uhm…

Come fa notare Uncle Bob, in questa situazione come in tantissime altre, la verità sta nel mezzo. Un pò di pianificazione all’inizio (senza arrivare agli estremi del BDUF), permette di capire meglio il problema e impostare una soluzione decente, senza rischiare di ficcarsi in un vicolo cieco da cui è molto difficile uscire.

Inoltre ci sono determinate cose che devono essere fissate up-front. Ad esempio, io mi sono ritrovato a lavorare ad un progetto di un sistema distribuito di simulazione, composto da diversi moduli che comunicavano in modo concorrente e tramite rete, ognuno progettato e realizzato da una parte del nostro team. E’ stato necessario definire:

architettura generale
interfacce di comunicazione
tipi di dato condivisi

Senza definire queste cose a priori non saremmo riusciti a lavorare in parallelo e ci saremmo pestati i piedi a vicenda rallentando l’intero progetto.

Management

Lo stesso concetto vale a livello di management, come ho verificato sulla mia pelle.

Anche qui si presenta il concetto di self-organizing team, ma è comunque necessario stabilire delle linee guida e delle regole (meglio se condivise e adottate su base consensuale), che andranno sì modificate e integrate “in corsa”, ma che sono comunque necessarie per una comunicazione efficace.

Avere un piano a livello di management significa poter identificare le priorità (infrastruttura, interfacce, user stories, ecc.), poter allocare risorse, pianificare costi e tempi di massima (ad esempio: project velocity di XP) e coordinare il team.

C’è un modo per affrontare con successo anche il progetto più gigantesco e complesso: fare un passo alla volta.

A: “voglio un di sistema di elaborazione di dati scientifici che si appoggia su CUDA pronto tra quattro mesi”
B: “comincia a studiare CUDA per una settimana e fai qualche prototipo, poi faremo un meeting per buttare giù qualche bozza di architettura e stimare i costi”

Quale delle due alternative ti motiva di più ed è più utile?

Conclusione

Sia in ambito tecnologico che in ambito gestionale occorre trovare un equilibrio tra pianificazione e auto-organizzazione, perchè ognuno dei due elementi è necessario alla buona riuscita di un progetto e di un team di sviluppo.

L'importanza di comunicare

2009-05-30T00:00:00-07:00

Non basta avere una buona idea, bisogna anche saperla “vendere”. C’è una concezione comune secondo cui “una buona idea si vende da sola” ma purtroppo non è sempre vero: basta guardarsi attorno per vedere delle ottime idee che non hanno riscosso un grande successo a causa di una “cattiva campagna di marketing”.

Una buona idea è un’orfana senza una comunicazione efficace.
– “The Pragmatic Programmer”, Andrew Hunt, David Thomas

Inoltre spendiamo buona parte delle nostre giornate comunicando (memo, email, discussioni con colleghi e management, interviste col committente, proposte di miglioramento, ecc.) per cui vale la pena farlo bene.

Personalmente mi sono trovato in molte situazioni in cui ho dovuto fare attenzione al modo in cui comunicavo per sostenere la validità del mio punto di vista. Ad esempio quando ho proposto il VCS Mercurial al team con il quale ho sviluppato un progetto all’università per ingegneria del software, o tutte le volte che abbiamo fatto delle presentazioni ai docenti del medesimo corso.

Come comunicare efficacemente

In “The Pragmatic Programmer” gli autori dedicano un capitolo a come comunicare efficacemente, in cui danno alcuni consigli che applicherò ai post di questo stesso blog e che riassumo qui.

Sapere cosa dire

Punto fondamentale e ovvio, ma troppo spesso ci si ritrova a digitare “Introduzione” e a cominciare a scrivere senza avere un’idea precisa di quello che si vuole comunicare.

E’ utile quindi pianificare quello che si vuole dire, ad esempio scrivendo un’outline e modificandola finché la risposta alla domanda “questo comunica quello che sto cercando di dire?” è sì.

Adattare il messaggio all’audience

Ogni idea può essere presentata in modi diversi a seconda dell’audience: ve ne sono di diverse con bisogni, interessi e capacità differenti. E’ quindi importante personalizzare il messaggio affinché sia recepito correttamente da chi sta ascoltando.

We’ve all sat in meetings where a development geek glazes over the eyes of the vice president of marketing with a long monologue on the merits of some arcane technology. This isn’t communicating: it’s just talking, and it’s annoying.

Occorre avere una chiara idea di chi ascolterà il nostro messaggio e delle sue caratteristiche. Le seguenti domande possono aiutare:

Che cosa vuoi che imparino?
Qual’è il loro interesse in quello che hai da dire?
Quanto sono sofisticati?
Quanti dettagli vogliono?
Chi vuoi che faccia propria l’informazione?
Come puoi motivarli ad ascoltarti?

Inoltre occorre adottare uno stile di comunicazione adatto. L’interlocutore preferisce andare dritto ai fatti oppure conversare? Preferisce uno stile formale o uno più sciolto?

Capire queste cose è importante per far recepire al meglio il messaggio.

Scegliere il momento giusto

Non ogni momento è il momento giusto. L’interlocutore può avere fretta, altro da fare o semplicemente può non essere dell’umore giusto. Una parte del capire le esigente dell’audience consiste nel capire le loro priorità, nel dubbio è sempre meglio chiedere: “è un buon momento per parlarti di …?”

Questo, almeno in un blog, non è un problema visto la natura intrinsecamente on-demand del mezzo di comunicazione :)

Cura l’apparenza

E’ uno sbaglio fare affidamento solo sul contenuto di un documento senza badare alla presentazione. L’aspetto è una caratteristica importante che concorre a veicolare efficacemente un’idea. Contenuto e aspetto devono essere curati in sinergia.

TIP 10: “It’s Both What You Say and the Way You Say It”

Alcuni suggerimenti per documenti:

usa un sistema di impaginazione che produca risultati gradevoli: ad esempio LaTeX, XHTML+CSS con eventualmente qualche exporter in PDF come FOP, DocBook, o anche qualche word-processor che supporti gli stylesheets.
usa lo spell-checking, prima automatico e poi manualmente (verifica walkthrough)

Coinvolgi l’audience

Un altro suggerimento (che non ho mai impiegato, mea culpa) è quello di coinvolgere gli interlocutori nel processo di produzione del documento per raccogliere feedback e instaurare una proficua relazione di lavoro.

Cosa che sembra abbia funzionato tra l’altro per la produzione di libri interi come Real World Haskell e Programming Scala.

Ragione per cui ho adottato questo approccio per il presente blog: nonostante il suo aspetto/layout sia ancora un work-in-progress è online e il repository dei suoi sorgenti è liberamente accessibile (in lettura) e pubblicato con licenza CreativeCommons.

Inoltre, nel caso di comunicazioni verbali è utile trasformare l’esposizione in una sessione interattiva, ad esempio facendo domande e chiedendo di riassumere quello che si è appena detto.

Desktop-search in KDE 4.2

2009-05-27T00:00:00-07:00

Da parte mia, una volta provata la funzionalità di desktop search è diventata irrinunciabile. E’ un utilissimo strumento per utilizzare il proprio computer con efficienza e significa avere tutti i propri dati e applicazioni letteralmente a portata di dita.

Niente più gerarchie di cartelle annidate e menu incastrati uno dentro l’altro come una matrioska. I dati memorizzati nel computer vengono indicizzati da un motore di ricerca e ogni file è raggiungibile non solo ricercando il suo nome, ma anche il suo contenuto. Possiamo aprire documenti, filmati, musica, applicazioni e chi più ne ha più ne metta in pochi secondi e dovunque si trovino su disco.

I vantaggi sono innegabili: io per esempio mi sono sempre trovato a dover gestire molti file (la maggior parte dei quali inutili) e a concepire sempre nuovi sistemi di archiviazione. Con il desktop search posso mettere tutto dentro una sola cartella (ad esempio “Archivio”) e raggiungere qualsiasi file al suo interno non appena ne ho bisogno, senza dover navigare alcuna gerarchia.

Piattaforme

Per MacOS abbiamo il migliore (mi dicono): Quicksilver.

Per Windows ci sono Google Desktop e Launchy (meno sofisticato di Google Deskop).

Su piattaforma Linux, per Gnome c’è GNOME Do e, per KDE, Nepomuk con il suo Strigi.

Usare Nepomuk con Ubuntu 9.04

Sfortunatamente Nepomuk non è ancora pronto per un’utilizzo di produzione e attualmente è abilitabile con facilità solo il rating e le annotazioni per i file.

Nonostante questo, con qualche passaggio manuale possiamo abilitare anche il motore di indicizzazione (Strigi), che poi potremo utilizzare con Dolphin o krunner.

Ecco i passaggi necessari:

Installare il backend di Strigi sesame:
```
sudo aptitude install soprano-backend-sesame
```
Attenzione: sarà necessario installare anche la la JRE!
Aprire il pannello:
```
System Settings > Advanced > Desktop Search
```
attivare “Enable Nepomuk Semantic Desktop” e disabilitare “Enable Strigi Desktop File Indexer”.
Eliminare i dati correnti di Nepomuk:
```
rm -Rf ~/.kde/share/apps/nepomuk
```
Configurare Strigi per usare il backend sesame nel file:
```
~/.kde/share/config/nepomukserverrc
```
e modificando la linea del backend nella sezione [main Settings] come segue:
```
Used Soprano Backend=sesame2
```

Sfortunatamente, in Ubuntu Jaunty Jackalope sesame è linkato al file libjvm.so, che però viene cercato nella posizione standard /usr/lib quando invece in Ubuntu si trova in un’altra posizione:

locate libjvm.so

nel mio caso:

/usr/lib/gcj-4.2-81/libjvm.so
/usr/lib/gcj-4.3-90/libjvm.so
/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/lib/i386/server/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/cacao/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so
/usr/lib/jvm/java-6-sun-1.6.0.13/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-6-sun-1.6.0.13/jre/lib/i386/server/libjvm.so

basta fare un link alla libreria server in /usr/lib, ad esempio:

ln -s  /usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so \
/usr/lib/libjvm.so

Tornare nel pannello “System Settings” nella sezione “Desktop Search” (vedi punto 2), e nella tab “Advanced Settings” selezionare quali directory far indicizzare da Strigi.
Abilitare Nepomuk e Strigi.

A questo punto dovrebbe comparire l’icona di Nepomuk nella task-list: ciò vuol dire che è partita l’indicizzazione.

Uso di Nepomuk

Il modo più semplice e diretto per usare Nepomuk è con krunner: Alt+F2.

Nell’area di inserimento che compare al centro dello schermo si possono:

lanciare applicazioni
cercare in contatti, bookmarks, file, documenti recenti, cronologia di navigazione
eseguire calcoli
esplorare certe cartelle con dolphin

E altro ancora, il tutto scrivendone il nome o anche una parte (krunner effettua il pattern matching).

krunner funziona anche senza Nepomuk e Strigi, ma con questi ultimi possiamo anche cercare all’interno dei propri file, con tutti i vantaggi che questo comporta.

Hello world!

2009-05-19T00:00:00-07:00

Ecco il primo post di questo mio nuovo blog! Finalmente mi sono deciso ad aprirlo, utilizzando il servizio GitHub Pages.

Si parte con un design molto minimale, creato a partire da quello di Tom Preston-Werner, il creatore di Jekyll e co-fondatore di GitHub.

Gli scopi di questo blog sono molteplici:

Per imparare qualcosa non basta leggere: metterlo in pratica e cercare di insegnarlo è uno dei metodi migliori per apprendere. Quindi questo è un posto in cui insegno prima di tutto a me stesso, e poi rendo anche disponibili questi lavori per aiutare che volesse intraprendere la stessa strada
Per condividere esperienze e instaurare dialoghi con persone che lavorano nel mio stesso campo
Last but not least, fare un pò di pratica con il web-design e pubblicare un sito in una maniera molto comoda e interessante :)

Enjoy!