Tarin Gamberini

A software engineer and a passionate java programmer

Raccolta di collegamenti su ergonomia, salute e produttività

Elenco dei collegamenti che ho raccolto negli ultimi mesi a seguito di fastidiosi dolorini dovuti all'uso intensivo del computer in posizione seduta per lavorare:

Test di unità o di accettazione?

Come sapere se un comportamento del software debba essere verificato tramite un test di unità o di accettazione? Una storia, che vede come miglior attore non protagonista un'intera razza di capre, ci aiuta a capire alcuni sottili differenze.

Introduzione a Cucumber

Quando un committente (stackeholder) ha una esigenza che vorrebbe fosse soddisfatta da un software deve, in genere, comunicare tale esigenza a qualcuno che lo sappia progettare e sviluppare.

Aldo: “Ci serve un software che faccia questo.”

Barbara: “Sì, a grandi linee mi sembra di aver intuito ciò di cui ha bisogno e penso che si possa fare. Per raccogliere ulteriori informazioni avrei bisogno di sapere con un po' più di dettaglio cosa intende con il termine «questo».”

Aldo: “Bhe, «questo» vuol dire che il software deve portare l'utente lì e là.”

Barbara: “Lì e là sempre?”

Aldo: “No no, deve portare lì quando l'utente si è registrato e poi clicca quiricchicchi, e solo quando l'utente ha nel carrello vari prodotti, e ha nel conto abbastanza lallarallà, deve portarlo là.”

Barbara: “Va bene, e relativamente ai lallarallà come fa il software a sapere quando ne abbiamo «abbastanza»?”

Aldo:

Per ridurre la spiacevole situazione in cui il software sviluppato faccia cose diverse da quelle comunicate i team agili hanno imparato a procedere per piccoli incrementi, al termine di ognuno dei quali si chiede al committente: “È «questo» quello che volevi?”.

Ma che fare quando «questo» non è quello che voleva il committente? Le incomprensioni, si sa, accadono, ma si possono ridurre? Esiste un modo affinché ciò che è stato comunicato guidi ciò che sarà sviluppato?

Digito ergo sum

È da più di un anno che ho iniziato ad usare Vim. Poiché ogni tanto mi capita di leggere confronti fra Vim (in inglese) ed Emacs (in inglese) ho deciso, incurante della guerra degli editor, di iniziare ad imparare qualcosa anche di Emacs.

Dalle prime pagine del manuale di Emacs ho capito che molti comandi sono raggiungibili con accordi: combinazioni di tasti normali e tasti modificatori (Alt, Ctrl, ecc…) premuti contemporaneamente. Questo modo di scrivere non mi è affatto nuovo, infatti programmando all'interno di IDE come Netbeans ed Eclipse faccio ampio uso di accordi.

Il sito web di Xah Lee

Cercando di capire quali svantaggi potessero comportare gli accordi mi sono imbattuto nell'articolo “Come evitare il problema del mignolo di Emacs (in inglese)”. Ho scoperto così il sito di Xah Lee, un guru dell'ergonomia della tastiera, di Emacs, e della digitazione in generale, che vi raccomando vivamente (in inglese) perché contiene moltissime informazioni utili a tutti coloro che usano pesantemente la tastiera del computer ed il mouse.