Tempo di migrazioni: trasformare un repository da svn a git

Un paio di giorni fa ho finalmente deciso di buttare a mare un vecchio repository svn per abbracciare git anche nell’ultimo progetto dove non lo utilizzavo, ecco quindi un sintetico tutorial su come trasformare un repository svn in repository git. Da parte mia ho seguito il tutorial di Atlassian, che però è abbastanza lungo e non tutti i passi erano necessari al mio scopo: trasformare un repository svn in repository git, una volta e per sempre, abbandonando poi il vecchio repository ma mantenendo tutto lo storico e gli utenti del vecchio repository.

Lo strumento

Di modi per fare questa trasformazione ce ne saranno parecchi, io ho usato il svn-migration-scripts.jar messo a disposizione da Atlassian, un classico eseguibile Java.
Scaricatelo e mettetelo nella home o dove preferite, ma tenente presente che i comandi seguenti sono stati scritti avendo il jar nella home dell’utente.

La preparazione

Detto che una migrazione andrebbe fatta in un momento idoneo possibilmente durante il quale il repository origine rimarrà inalterato, che dovrebbe essere eseguita da chi di dovere, e che se si vuole velocizzare le operazioni bisognerebbe lavorare sulla stessa macchina del repository svn o quantomeno nella stessa lan, ipotizziamo che sia tutto a posto e iniziamo.

Per prima cosa bisogna verificare le precondizioni, ovvero accertarsi che sul sistema ci sia tutto il necessario per eseguire la conversione.
Eseguendo il jar con il parametro “verify” viene controllato il sistema con stampa a video delle eventuali mancanze.
java -jar ~/svn-migration-scripts.jar verify
Se state eseguendo la migrazione su un Mac bisogna prima creare e montare un disco case-sensitive, sul quale sarà creato il nuovo repository:
java -jar ~/svn-migration-scripts.jar create-disk-image 5 GitMigration
L’esecuzione di questo comando crea un disco chiamato “GitMigration”

Mapping degli utenti

Nel vecchio repository i commit erano associati a utenti identificati da un nome, ma su git gli utenti sono identificati da nome e email. Andiamo quindi a creare – dentro il disco virtuale creato al passo precedente – un file authors.txt contenente il mapping tra vecchi e nuovi utenti.
cd GitMigration
java -jar ~/svn-migration-scripts.jar authors svn://repository_url/repository_name > authors.txt
Questo crea un file di mapping contente sulla sinistra i nomi degli utenti presenti sul vecchio sistema, e sulla destra i nomi e le email da usare sul nuovo sistema. Naturalmente quelli di destinazione sono solo ipotesi, e infatti le email sono di pura invenzione (le email sono tutte nella forma “username@mycompany.com”). Andiamo quindi a sostituire le email e se vogliamo i nomi degli utenti, salviamo e passiamo al punto successivo.

Clonazione del repository

È finalmente giunto il momento della trasformazione… ma qui lo script di Atlassian ci abbandona e il git inizia a farla da padrone.
Se il repository svn di partenza ha una struttura standard, con un “trunk” contenente il codice del ramo principale, una cartella “tags” contenente tutti i tags e così via possiamo lanciare il comando seguente, con parametro “stdlayout”.
git svn clone --stdlayout --authors-file=authors.txt svn://repository_url/repository_name new_repository_name
Se al contrario abbiamo una struttura non così standard possiamo andare a specificare dove devono essere letti i dati relativi a trunk, branches e tags. Nel mio caso il trunk non era presente perché i sorgenti del ramo principale erano semplicemente in una cartella nella root del repository, quindi non ho potuto usare il parametro “–stdlayout” e ho dovuto specificare le destinazioni delle varie cartelle.
git svn clone --trunk=/folderName --branches=/branches --tags=/tags --authors-file=authors.txt svn://repository_url/repository_name new_repository_name

La trasformazione generalmente richiede alcuni minuti, pochi se avete solo qualche centinaio di commit e siete in lan (o meglio ancora sulla stessa macchina del repository), molti di più se state lavorando con un repository enorme che risiede dall’altra parte del mondo.
Al termine dell’esecuzione nel disco virtuale “GitMigration” comparirà il neonato repository git, ovvero una cartella contenente i sorgenti e tutti i dati necessari a git (la cartella nascosta .git).

Pulizia del repository git

Il repository git creato al passo precedente è ancora “collegato” a svn, infatti l’origin punta al vecchio repository e tutto è “costruito” in modo da poter continuare a centralizzare i commit sul vecchio repository.
Se il nostro obiettivo è quello di tagliare i ponti con il passato, abbandonare svn e creare un nuovo origin git, quello che dobbiamo fare ora è lanciare lo script necessario per trasformare branches e tags nel classico formato git.
java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git --force

Creazione di un nuovo origin

La trasformazione è ormai compiuta e non ha più senso mantenere nel nuovo repository un riferimento al vecchio repository svn, conviene quindi eliminare l’origin e crearne uno nuovo.
Andiamo quindi a creare sul server più adatto a mantenere una copia dei nostri sorgenti un repository git.
Spostiamoci sul server, creiamo una cartella repository_name.git, settiamone i permessi/gruppi/proprietario, e inizializziamo il repository con il comando git init --bare repository_name.git.
A questo punto non resta altro da fare che modificare l’origin del repository git sostituendo l’url del vecchio repository svn con quello del repository remoto appena creato (utilizzando il protocollo che riteniamo più adatto, nel mio caso l’ssh), eseguire il primo push e il gioco è fatto.

Come server dei sorgenti nessuno ci vieta di utilizzare servizi web come BitBucket o GitHub, ma se il cloud vi fa paura un server linux in locale va benissimo, anche perché essendo git un sistema decentralizzato e distribuito eventuali problemi al server non sarebbero la fine del mondo.

Se al termine qualcosa non vi torna (ad esempio non riuscite a togliere il vecchio origin come è successo a me) un nuovo clone del repository remoto non guasta, anche per verificare che sul server sia tutto a posto.

Conclusioni

Nessuno ci obbliga a sostituire il sistema che usiamo per fare il versioning dei nostri progetti, ma se inizierete a usare git vedrete che il gioco vale la candela e presto o tardi ne sentirete la mancanza quando dovrete tornare all’svn o peggio a sistemi ancora più vecchi. Si può decidere di trasformare il repository in git continuando a mantenere svn sul server, ma secondo me se si decide di cambiare conviene farlo in modo netto, e con i semplici passi che ho elencato la transizione dovrebbe essere veloce e indolore.

Il perfetto binomio computer e vita dei campi

Oggi niente tecnologia, e non parlerò nemmeno di Rosso Malpelo o de La Lupa. Quello che voglio analizzare è un mio esperimento che sto portando avanti da qualche mese.

L’esperimento

L’estate scorsa ho iniziato uno strano percorso, un tentativo di mescolare il lavoro di ufficio con un po’ di lavoro nei campi. Numerosi sono i motivi che mi hanno portato a chiedere una riduzione di orario e ci ho pensato per lungo tempo, finché quasi un anno fa mi sono deciso e ho chiesto al boss dell’azienda dove lavoro un periodo di prova in questo senso, che mi è stato gentilmente concesso.
Inizialmente chiesi di poter fare soltanto cinque ore al giorno per venticinque ore settimanali, ma mi sono presto reso conto che erano un po’ pochine sia economicamente che professionalmente, ci siamo assestati quindi sulle trenta ore settimanali con periodici e temporanei aumenti a trentacinque nei momenti di maggior carico di lavoro. Ridistribuendo l’orario in modo un po’ più efficiente mi ritrovo così ad avere quattro mezze giornate libere a settimana (più il sabato), e tre mezze giornate libere nei periodi di maggior lavoro in ufficio (quando faccio le 35 ore settimanali).
Naturalmente si potrebbe obiettare che per lavorare all’aperto bisogna considerare anche le poche ore di luce invernali, e infatti il patto è che in inverno (novembre-marzo) le mezze giornate libere ce le ho la mattina, mentre da aprile a ottobre ho liberi i pomeriggi… guarda caso durante l’ora legale, che fosse per me dovrebbe essere estesa a tutto l’anno.

Il grano è un po' fuori luogo ma l'immagine dovrebbe rendere l'idea

Il grano è un po’ fuori luogo ma l’immagine dovrebbe rendere l’idea

L’impatto iniziale

A onor del vero va detto che qualche ettaro di terra la mia famiglia l’ha sempre avuto e i miei genitori e zii hanno dedicato quasi tutto il loro tempo libero a vigna, olivi e orto. Io ci sono venuto su fin da piccolo e quindi avevo già ben presente cosa significhi lavorare d’inverno all’aperto e/o farlo “nel tempo libero”. Non ho dovuto fare alcun tipo di spesa né di preparativo perché era già tutto lì, se così non fosse stato e non avessi avuto motivi personali non credo avrei mai fatto una mossa simile… anche perché come tutti i nerd che si rispettino preferisco il computer.

Effetti sulla salute

È innegabile che lo stare sempre seduto alla scrivania alla lunga non sia il massimo per un essere umano, il quale ha bisogno anche di movimento e soprattutto di stare all’aria aperta. Nei periodi di lavoro continuativo nella vigna – quali ad esempio vendemmia, potatura invernale, legatura e sfogliatura – ho notato meno fastidi a schiena, collo e polsi. Inoltre so per certo che lo stare di più sotto il sole aumenti l’assunzione di vitamina D, e per esperienza personale dico che passare le ore diurne dell’inverno tra casa, auto e ufficio può portare a grosse carenze vitaminiche, con tutti i problemi che potrebbero derivarne.
Qualche ora di sana fatica fisica favorisce anche il mantenimento del peso e aiutano a dormire meglio la notte, è molto più difficile infatti superare la mezzanotte senza aver voglia di sdraiarsi sul letto. Un altro effetto dell’alternanza sono delle giornate meno monotone – giornate che prima si susseguivano sempre una uguale all’altra – e il tempo scorre più lentamente: le settimane sembrano ora un po’ più lunghe.
Ultimi ma non meno importanti i benefici per la vista, perché i nostri occhi non sono fatti per fissare tutto il giorno delle superfici (libri o monitor che siano), e il maggior controllo dello stess.

Dall’altra parte della bilancia c’è da mettere maggior usura delle mani, possibili sbilanciamenti nella postura se quando si compiono sforzi o lavori ripetitivi si cerca di farli sempre “come rimangono più alla mano”, forse qualche raffreddore e screpolamento di mani e labbra in inverno, qualche abbronzatura non proprio uniforme in estate, qualche puntura di insetto e il rischio di qualche taglio/graffio. Niente però che subito ogni tanto non rafforzi organismo e sistema immunitario.

Il portafogli

Il lavoro che faccio a casa è a titolo gratuito, e il numero di ore non è nemmeno lontanamente paragonabile a quelle del mio impiego principale. Lo stare ancora in famiglia a trent’anni suonati e il mio stile di vita frugale senza troppi vizi fanno sì che la riduzione dello stipendio (già prima abbastanza misero) non diventi un grosso problema, e a conti fatti in questo modo posso anche dire di pagarmi il vitto e l’alloggio.
Lo stipendio ne risente in proporzione, ma il minor impatto fiscale su un imponibile che è per forza di cose minore e la riduzione delle spese dovuta al minor numero di viaggi casa-lavoro compensano in parte questo aspetto negativo.

I contributi previdenziali calano in proporzione, ma considerato che questo paese è allo sfascio e che quasi sicuramente la maggior parte dei ragazzi della mia generazione e di quelle a venire non vedranno mai la pensione questo problema al momento non mi pesa troppo. Fosse per me smetterei di pagare i contributi e mi riprenderei anche quelli già versati, investendoli per mio conto, ma in questo modo tutto il sistema su cui si basa il racket dell’Inps crollerebbe con grande dispiacere di quell’esercito di parassiti andati in pensione troppo presto a causa di quell’altro esercito di prostitute politiche che ci hanno governato negli ultimi quarant’anni. Ma questa e un’altra storia, l’importante per quanto mi riguarda è non farsi condizionare nelle scelte di oggi da un evento a probabilità quasi zero che potrebbe accadere tra quarant’anni, cercando al tempo stesso di ottenere il massimo in questo senso con il minimo sforzo.

Impatto sul proprio lavoro “principale”

Il lavoro di analista/sviluppatore software è potenzialmente uno dei più dinamici che si possa scegliere, e richiede moltissimi sperimentazione e studio se si vuole restare al passo con la tecnologia e se si vuole essere in grado di sviluppare progetti “completi” in tutte le loro parti. L’ottimo sarebbe lavorare almeno quaranta ore a settimana in ricerca e sviluppo seguendo più progetti in tecnologie diverse, ma se al lavoro si tende a fare quasi sempre gli stessi lavori una riduzione di tempo non porta grandi effetti.
Purtroppo in molte aziende si tende a “specializzare” un po’ troppo i dipendenti assegnando loro compiti il più possibile uguali, e sebbene molti ne siano felici perché così si siedono e sanno sempre cosa fare e come farlo, questo porta ad un lento e inesorabile decadimento delle capacità di apprendimento, delle conoscenze, e dell’elasticità mentale di costoro. Lavorando in un’azienda di dimensione medio-grandi (almeno per una regione come le Marche) mi capita di vedere questo “tarlo” all’opera molto spesso, e posso dire che chi si lascia mangiare abbastanza a lungo poi molto difficilmente riesce a riprendersi, e a un certo si ricicla in qualche modo anche perché non è più in grado di fare il proprio mestiere.
Io di rado ho avuto la fortuna di fare ricerca e sviluppo, e lo stare sempre avanti al computer al lavoro aveva quasi azzerato la mia voglia di farla a casa. Riducendo l’orario e riorganizzandolo meglio adesso ho più tempo di studiare e sperimentare a casa (dopo cena e quando fa brutto tempo), tanto che sono certo di poter ampliare e aggiornare le mie conoscenze più facilmente ora che prima.

Strani fenomeni aziendali

In quasi tutte le aziende di informatica più grandi si verifica uno strano e pericoloso fenomeno, tanto che in alcune di queste si cerca di “svecchiare” la forza lavoro spingendola ad andare via alla soglia dei cinquant’anni.
Quando uno sviluppatore bravo è assunto da abbastanza tempo diventa “responsabile” di qualcosa, e lentamente smette di lavorare involvendo professionalmente e diventando inetto (chi più chi meno) al proprio mestiere. L’esperienza accumulata nel passato inizialmente lo rende un buon analista, ma smettendo di fare e di saper fare anche questa capacità degrada velocemente, finché non sa più rendersi realmente utile e non gli resta altro da fare che parlare con i clienti e/o dare ordini, in entrambi i casi spesso senza cognizione di causa. Questo male colpisce quasi tutte le aziende di informatica non giovani.
Organizzazioni aziendali moderne ed efficienti dovrebbero sfruttare il più possibile le risorse nella produzione limitando quelle organizzative al minimo. Ponendo filtri tra chi fa il lavoro e chi lo richiede (il cliente) si verificano inoltre altri effetti collaterali, quali latenze nelle comunicazioni e molto spesso la realizzazione non di cosa ha bisogno il cliente ma di quello che “chi ci ha parlato” ha capito… vero che un po’ di analisi va fatta a monte, ma quella vera si fa mentre si scrive il codice. Seguendo queste logiche perverse si incappa anche in una minore crescita professionale di chi scrive il software perché questi non può apprendere dal cliente le loro reali logiche di business ma deve accontentarsi di ciò che gli viene detto dal “responsabile” di turno.

Forse sono uscito un po’ troppo dal “somentado”, ma dire che negli ultimi mesi ho aperto questo blog, fatto non so quanti corsi web su CodeSchool e ripreso a leggere con un minimo di continuità libri tecnici dovrebbe bastare per capire che professionalmente parlando la mia scelta non ha impattato negativamente.

Varie ed eventuali

Un altro effetto positivo è il maggior tempo che ho ora di ascoltare podcast e audiolibri. Quando si fanno lavori ripetitivi in vigna è un piacere mettersi le cuffie e ascoltarsi qualche audiolibro o corso di lingua per intervallare il piacevole (a piccole dosi) rumore della campagna. Consiglio a tal proposito di frugare su Librivox (ascoltare Mastro don Gesualdo mentre si pota è impagabile), e di provare alcune lezioni di English for Italians.

Oltre al lavoro di sviluppatore software ce n’è un altro che in questo paese è considerato al livello di bassa manovalanza mentre in altri paesi è (giustamente) molto ben pagato perché richiede molte conoscenza ed esperienza, quello di viticoltore/potatore di vigna. Dice il vecchio adagio “impara l’arte e mettila da parte”, apprendere questo mestiere direttamente da chi lo conosce bene può sempre tornare utile.

Nuove amicizie

Nuove amicizie

Bilancio momentaneo (a dieci mesi)

Ormai sono passati dieci mesi, un periodo abbastanza lungo per tirare delle somme.
Il lavoro nei campi non è per tutti e a me piace molto di più progettare e sviluppare software, ovvero analizzare problemi e cercare di risolverli, è questo il mio lavoro e non credo ce ne siano altri che possono riuscirmi meglio.
Qualche mezza giornata di lavoro manuale nella vigneto e nell’oliveto aiutano a restare in forma, a farsi piacere maggiormente il proprio lavoro “principale”, e a distendere i nervi. Specialmente quando nella vigna si fanno lavori quali la potatura invernale, la legatura o la sfogliatura estiva (per dirne alcuni) – operazioni abbastanza monotone e in cui non è necessario rimanere concentrati – si ha il tempo di stare da soli lasciando la mente libera di vagare come più le piace. In questi momenti capita di pensare a soluzioni per risolvere problemi in ufficio, alle proprie relazioni personali, capita di avere idee di ogni genere. E la sera si va a dormire con quel po’ di stanchezza in più che aiuta a dormire meglio. Inoltre il doversi confrontare con sfide molto diverse da quelle che si incontrano in ufficio aiuta a ragionare in modo più “ampio”. I problemi sono sempre problemi, e anche nei campi si fa pur sempre del problem solving.
Nel complesso mi sembra di stare meglio fisicamente e mentalmente, e dal mio punto di vista tutti dovrebbero poter avere qualche mezza giornata libera per dedicarsi a qualche forma di lavoro all’aria aperta, perché ne giovano la qualità del lavoro e soprattutto la qualità della vita, che poi è la cosa più importante.

Un paio di release fa

Un paio di release fa

Draw 9-patch: le immagini auto-adattanti di Android

Qualche tempo fa – dopo mesi di sviluppo multi-piattaforma su Titanium per una sola piattaforma (iOS) – finalmente mi è capitato di dover mettere mano anche al lato verde dello sviluppo mobile, quello della piattaforma Android.

Su un progetto mi è stato mostrato un tool presente solo su Android per generare immagini auto-adattanti al contenuto e al contenitore – il Draw 9-patch – utilizzato in un progetto per generare l’immagine “splash” dell’applicazione. Ora finalmente mi sono ricordato che mi ero detto di approfondire un po’ la cosa, e ho notato che non c’è molta documentazione al riguardo (almeno in italiano), quindi eccomi qui.

La “tecnologia”

Quelli di Google non hanno badato a spese per progettare e realizzare questo formato di file… si tratta infatti di una semplice immagine png con estensione .9.png, e contenente delle righe nere all’interno del file.
Sviluppando in nativo questi immagini devono essere piazzate dentro la directory res/drawable, utilizzando Titanium invece vanno dentro assets/android.

Esempio di immagine 9-patch

Esempio di immagine 9-patch


Sui lati dell’immagine si possono tracciare delle righe nere (solid) di un pixel, ciascuna delle quali ha un significato. Quelle sui bordi superiore e sinistro definiscono la/le superfici che possono essere “stirate” (stretched), mentre sulla destra e sotto si possono (opzionalmente) tracciare le righe che definiscono le aree che possono essere riempite – adattandone le dimensioni – con del contenuto, come ad esempio testo o altre icone.
I bordi superiore e sinistro sono fondamentali quando si vogliono creare degli splash screen adattivi, quelli destro e inferiore al contrario servono soltanto se l’immagine che si sta creando serve da sfondo per pulsanti o contenitori, all’interno dei quali si dovranno inserire testo e/o altre immagini.
Questi bordi, presenti nell’immagine “sorgente”, saranno poi naturalmente eliminati dall’immagine risultante.

Da notare come l’intersezione dei bordi superiore e sinistro, e quella dei bordi inferiore e destro formino delle superfici, superfici che chiaramente non possono essere “negative”. Queste immagini possono quindi adattarsi soltanto aumentando di dimensione, e non scaleranno mai più dell’immagine originaria, che deve quindi essere considerata come caso “più piccolo”.

Il tool Android fornito con l’SDK

All’interno dell’SDK di Android, e più precisamente nella directory sdk/tools, si può trovare il potentissimo strumento per gestire questi tipi di file. Su Windows si lancia con il bat draw9patch.bat.
Draw9patch - Tool
Trattasi di un eseguibile java che prende in ingresso un file png e – attraverso opportuni trascinamenti dei bordi – permette di definire quali aree sono adibite allo “stretching” (stiramento) e quali al “filling” (riempimento).

Senza scomodare tool sconosciuti: Gimp

Stiamo lavorando con un’immagine png, nessuno ci vieta quindi di utilizzare il nostro editor di immagini preferito, nel mio caso Gimp.
Draw9patch - Gimp
Se decidiamo di utilizzare un editor, qualunque esso sia, bisogna però fare attenzione che questo non aggiunga artefatti, trasparenze non volute o anti-aliasing che possano “rompere” le convenzioni del 9-patch Android. Una volta modificata l’immagine forse conviene quindi andare a testarla su dispositivi diversi per verificare che il risultato sia sempre quello atteso.

Test su emulatore Genymotion

Test su emulatore Genymotion

Profilare con Xcode, alla ricerca di memory leaks e non solo

Chi fa il nostro mestiere prima o poi deve affrontare dei problemi di memoria… che la si perda a causa di stress e del passare degli anni, o si scriva programmi che si affidano ad allocazione/deallocazione automatica, prima o poi tutti abbiamo problemi con questo prezioso strumento.

Il caso peggiore: memory leak in applicazione web Java

Tempo fa lavorando ad un grosso progetto web sviluppato in Java (JSF2) ci ritrovammo a metterci le mani nei capelli a causa di qualche memory leaks che rendevano per così dire “poco scalabile” la nostra applicazione. Allora usammo l’Eclipse Memory Analyzer MAT, strumento molto potente e ben fatto che permette di analizzare lo heap di qualunque applicazione Java.
Su un’applicazione web certi problemi possono essere devastanti, mentre in programmi che girano localmente su macchine provviste di parecchia RAM spesso nemmeno ci si rende conto che il nostro programma sta lentamente mangiando tutta la memoria senza rilasciarla, finché va in crash. Se però questa cosa succede di rado, e in quelle poche occasioni stavamo facendo operazioni parecchio onerose, spesso nemmeno ci facciamo caso e/o facciamo finta di niente.
Memory Leak - Comic

Memory leak?

Se non siete uno degli ultimi due personaggi della vignetta dovreste sapere a grandi linee di che si tratta, ma nel dubbio cerco di spiegarlo in poche parole: un programmatore ha sbagliato qualcosa e tra le righe di codice c’è qualche operazione che occupa memoria senza rilasciarla al termine.
Se non si programma in C raramente ci si deve preoccupare di allocare e deallocare la memoria manualmente, perché quasi tutti i linguaggi gestiscono la memoria autonomamente, allocandola ad ogni nostra dichiarazione di variabile, e facendola liberare da un garbage collector. Il GC è un processo demone che scansiona l’area di memoria dove risiedono gli oggetti e le variabili creati dal nostro programma ed elimina quelli rimasti per così dire “isolati”, ovvero che non sono più referenziati da nessuno o che sono collegati solo a oggetti non referenziati da parti “vive” dell’applicazione. In presenza di GC i memory leak sono rari perché il GC a differenza nostra non si dimentica di liberare la memoria, ma a volte proprio non ce la fa a causa di strutture mal progettate che generano riferimenti “eterni” a variabili che credevamo temporanee, e in questi casi sono dolori.

Tipico grafico di un'applicazione affetta da memory leaks, lo heap si riempe e boom

Tipico grafico di un’applicazione affetta da memory leaks

Analisi della memoria su Xcode

Sviluppando in nativo su iOS non so quanto spesso capiti di dover profilare l’applicazione alla ricerca di problemi di memoria, ma parlando di Titanium io personalmente ho dovuto preoccuparmene in più di un’occasione. Il Mac è un prodotto del demonio, però Xcode fornisce alcuni validi strumenti che in questi frangenti tornano molto utili. Vediamo come profilare un’applicazione alla ricerca di problemi di memoria e di prestazioni.

Aprendo un progetto Xcode ci si trova di fronte la finestra delle impostazioni generali, e qui dobbiamo definire le impostazioni di deploy. Generalmente la versione di iOS e il tipo di dispositivo.
IOS Profiling 1
Scegliamo la destinazione del nostro test, tra eventuali dispositivi collegati al Mac e simulatori del tipo selezionato al passo precedente. Fatto questo dobbiamo ricompilare il progetto. Considerato che stiamo per fare una profilazione, tanto vale fare il “Build for > profiling”, e al termine avviamo la profilazione con “Profile”.
IOS Profiling 2
Selezioniamo il tipo di template che più si adatta alle nostre esigenze o creiamo un template contenente tutte le metriche che ci interessano.
IOS Profiling 5
Nella schermata che si apre, quando siamo pronti, premiamo il tasto di registrazione e l’applicazione inizia a girare mandando dati agli strumenti di diagnostica scelti.
In cima all’elenco possiamo leggere istante per istante i dati generali i utilizzo della memoria, e subito sotto quali sono i tipi di oggetti che contribuiscono in maggior misura a saturare la nostra cara RAM. Il diagramma parla più di tutti, se questo inizia lentamente ad assomigliare ad una sega inclinata verso l’alto sono cazz… problemi.
IOS Profiling 6
Se certe parti del flusso del programma sono sospette e volete vedere in dettaglio come cambia l’utilizzo della memoria facendo una determinata operazione non serve segnarsi i numeri sul foglio ma possiamo usare l’utilissimo pulsante “Mark generation”. Questo serve a scattare un’istantanea di un certo punto, istantanee che possono poi essere confrontate per vedere come cambia l’utilizzo della memoria tra queste diverse “generazioni” (e quali oggetti rimangono in memoria).
Nel mio caso la memoria rimane stabile e decresce alla chiusura di alcune finestre parecchio pesanti. Se in certi punti pensate ci siano dei memory leak ma i “buchi sul tubo” sono troppo piccoli da rilevare potete prendere un trapano e allargare il buco… basta aggiungere delle immagini o in generale blob pesanti in variabili sospette per vedere meglio la RAM che se ne va.
IOS Profiling 7

Sviluppo per iOS su Titanium

Se stiamo sviluppando con Titanium probabilmente Xcode lo conosciamo molto poco, eppure nella vostra cartella del progetto (sotto build/iphone) ci dovrebbe essere un file .xcodeproj. Apritelo e vi ritroverete con il progetto Xcode che potete maneggiare e lanciare a piacimento

La cartella del progetto iOS generato da Titanium

La cartella del progetto iOS generato da Titanium

Senza scomodare Xcode

Certi strumenti sono molto potenti e possono aiutarvi molto, ma se siete dei romantici e preferite migliorare le prestazioni del vostro programma basandovi solo sull’intuito potete comunque usare la finestra di Monitoraggio delle attività di OSX. Ogni programma lanciato nel simulatore iPad/iPhone è un processo a se stante, e potete quindi tenere sempre sott’occhio la memoria che questo utilizza.

Monitorare il processo spesso è sufficiente

Monitorare il processo spesso è sufficiente

Intuito, Xcode, oscilloscopio, qualunque mezzo decidiate di usare l’importante è che ogni tanto verifichiate la stabilità e la non eccessiva onerosità dei vostri programmi. Alcuni utenti non sono molto comprensivi – giustamente – quando l’applicazione si rallenta in modo esagerato con il passare del tempo o peggio scompare dalla loro vista all’improvviso.

Lavagne per tutto e per tutti: Kanban board

Quando si entra in aziende che lavorano in modo agile – o per meglio dire lean – balzano subito all’occhio delle grosse lavagne ricoperte di foglietti. Quelle lavagne non fanno solo “figo”, ma rappresentano l’appiattimento delle gerarchie e la distribuzione dell’informazione in basso perché servono, tra le altre cose, a fare in modo che tutti possano sapere in ogni momento cosa si sta facendo in azienda e chi lo sta facendo.
Chiaramente nelle organizzazioni aziendali classiche, piramidali e spesso monolitiche, chi ha la “fortuna” di stare in alto non ha interesse a far sapere ai sottoposti più dello stretto necessario allo svolgimento del loro lavoro, e queste lavagne si vedono solo raramente per qualche iniziativa estemporanea del singolo. Eppure anche se si è l’ultima ruota del carro una lavagna di questo tipo può essere molto utile.
Inoltre la storia ci dice che a un certo punto anche una cività apparentemente eterna come quella dell’Antico Egitto si è sfaldata ed è stata sostituita da altre, quindi meglio prepararsi.

Kanban, sempre con questi nomi inglesi

No, niente inglese per una volta. Kanban è un termine giapponese ed è diventato celebre principalmente grazie alla Toyota e al loro sistema di gestione della produzione Just in time. Dovrebbe bastare questo per capire che lo strumento è tutt’altro che appannaggio del mondo dello sviluppo software e che può essere utilizzato in tutti quei contesti dove non si è soddisfatti dei tempi e dei modi in cui determinate operazioni vengono svolte.

Perché si usa una Kanban board

Come già anticipato questo strumento – specialmente se attaccato a un muro – ha il potere di far fluire l’informazione all’interno dell’azienda, migliorando anche la collaborazione tra le varie parti.
Se usata nel modo opportuno si riesce inoltre a valutare a colpo d’occhio il lavoro in attesa di essere svolto, quello in fase di lavorazione, e come si distribuiscono i compiti i vari collaboratori. Il WIP (Work In Process) non deve essere eccessivo in relazione al numero di persone al lavoro, e una Kanban può aiutare a tenerlo abbastanza alto da mantenere sostenuta la produzione, ma non troppo da inficiarne l’efficienza.

Effetti dell'aumento eccessivo del WIP

Effetti dell’aumento eccessivo del WIP


Se poi si vuole fare un lavoro con i fiocchi e si inserisce in ogni foglietto la data di inserimento nel backlog (data di richiesta), la data di inizio lavorazione e quella di fine lavorazione, è possibile calcolare per ciascuna attività il cycle time (tempo di lavorazione) e il lead time (il tempo intercorso tra la richiesta e la consegna), e con questi dati ottenere delle preziose metriche del lavoro svolto (tempi di lavorazione medi, tempi di consegna medi e così via), metriche utilissime per individuare colli di bottiglia e per cercare di migliorare il funzionamento aziendale.

Tangibile o no

Le scuole di pensiero sono diverse – come sempre – e qualcuno è convinto che nell’era digitale tutto debba essere fatto di bit. Com’è naturale ogni soluzione ha le sue peculiarità e i suoi punti di forza, tutto sta valutare i pro e i contro e scegliere di conseguenza.

Lavagna digitale

Ci sono svariati servizi web, a pagamento o non, che permettono di creare la propria Kanban board (o qualcosa di molto simile) e di condividerla con la propria squadra. I vantaggi principali di affidarsi al digitale risiedono nel poter avere accesso alla propria lavagna ovunque ci si trovi, e di poterla condividere con chi si vuole. Si può gestire una profilazione in base alla quale diversificare i permessi di accesso, e avere a disposizione delle metriche sempre aggiornate. Inoltre a seconda del servizio scelto si potrebbe anche pensare di mettere in piedi integrazioni con altri strumenti per gestire i propri progetti nel modo più automatico possibile.
Lo strumento principe in questo momento è sicuramente Trello, ma l’offerta è enorme e ci sono anche soluzioni gratuite e open-source come Kanbanik.

Welcome board di Trello

Welcome board di Trello

Lavagna reale

Occupa spazio a parete e bisogna attrezzarsi del materiale necessario, scegliendo tra lavagne magnetiche o non, o semplici rotoli di carta. Fatto “l’investimento” iniziale bisogna poi continuare a spendere per post-it e/o pennarelli.
Se prendiamo questa strada scordiamoci integrazioni varie, profilazione degli accessi, calcolo automatico delle metriche, accesso remoto e tutto ciò che è prerogativa del digitale. Eppure per molti è ancora questa la strada da preferire, perché una lavagna fisica è sempre sotto i nostri occhi ed è più piacevole da manutenere. E cosa da non sottovalutare fa anche design.

La mia soluzione

Ciascuno ha le proprie esigenze, io per quanto mi riguarda ho optato per una lavagna metallica Nobo senza cornice, una soluzione che mi da la possibilità di estendere eventualmente la dimensione della mia lavagna, e per evitare che i foglietti cadano ogni due minuti (e non usare nastri adesivi) mi sono attrezzato con tanti piccoli magnetini.

La Kanban che uso al lavoro per gestire i progetti a cui partecipo

La Kanban che uso al lavoro per gestire i progetti a cui partecipo


Ho diviso la superficie orizzontalmente per progetti, e verticalmente per “livelli del software”, ciascun livello con le proprie aree todo e done. Non ho lasciato uno spazio per le attività doing perché per marcare le attività in corso uso semplicemente dei magneti più grandi e colorati.
Essendo la mia “Kanban personale” e lavorando quasi completamente da solo non ho bisogno di altro, ma se anche si volessero gestire le “identità” di coloro che sono al lavoro su un determinato compito basterebbe diversificare i magneti, associando a ciascuno un colore diverso (o meglio ancora degli avatar). Il massimo numero di attività svolte da un soggetto in un determinato momento è limitato dal numero di magneti assegnati a costui; generalmente due-tre magneti sono sufficienti, perché un parallelismo più alto sarebbe deleterio e significherebbe che alcune di queste attività sono in realtà ferme.
La priorità è identificata dal colore del foglietto, gialla per le cose a priorità bassa, rosso per quelle che devono essere fatte con maggior urgenza. La priorità del backlog è data dall’ordine dei foglietti all’interno dell’area todo.
La lavagna è piccola (70 x 35 cm), ho usato quindi dei post-it più piccoli.
Eventuali informazioni aggiuntive, come ad esempio la versione del software rilasciata al cliente, le aggiungo con il pennarello in aree determinate.

I limiti della mia lavagna

Nella mia Kanban non è chiara la priorità “generale” dell’attività, perché le priorità sono evidenti solo all’interno di ciascun progetto.
Quando dovrò iniziare a lavorare a qualche altro progetto non avrò più spazio, dovrò quindi fare un sacco di spostamenti (ma potrei in teoria comprare altre due lavagne). Inoltre se un cliente si incavola e un’attività diventa urgente dovrei riscrivere l’attività su un nuovo foglietto di colore diverso.
Lo spazio su ciascun foglietto è poco, quindi non ho prestato molta attenzione alle date di inserimento nel backlog, di inizio attività e fine attività. Inoltre ho dovuto scrivere abbastanza piccolo e la mia calligrafia non è il massimo (eufemismo), quindi i coraggiosi che volessero leggere le attività potrebbero avere qualche problema.
Il punto è che a me non interessa poi tanto valutare i tempi, quanto avere sempre a disposizione una “fotografia” del mio lavoro vicino alla mia scrivania, così che chiunque voglia sapere cosa sto facendo (anche in mia assenza) possa vederlo velocemente con i suoi occhi (me compreso).

Conclusioni

Come consigliato una sera dal coach agile Stefano Leli, la Kanban va introdotta anche senza permesso dei superiori perché è uno strumento virale, che colpisce e cattura l’attenzione di chiunque la veda.
Mantenerla non richiede più del tempo che fa guadagnare, e anche se dovrebbe servire a coordinare un gruppo di persone può essere molto utile anche a chi lavora per proprio conto.

Io ne ho anche una attaccata dietro la porta della mia camera, con cui voglio cercare di mantenere bilanciato il tempo che dedico allo svago, alla formazione personale e alle attività domestiche. Ma questa è un’altra storia.

L’importante è capire che “Lo scopo di Kanban è quello di eliminare Kanban” (Mike Rother).

Generare il proprio modello di business con i canvas

Era il lontano novembre 2013 quando al Cowo 42 l’agile coach Stefano Leli tenne un illuminante seminario dal titolo “Dalla Vision al Prodotto”. Ero con alcuni miei colleghi e tutti ci divertimmo un sacco a giocare con post-it e cartelloni per esplorare velocemente un’idea di progetto, ma quello che apprendemmo allora rimase più o meno nel cassetto, almeno nel mio caso.

Forse quindici mesi fa i tempi non erano maturi per introdurre nell’azienda dove lavoriamo certe metodologie, ma qualche settimana fa Francesco Strazzullo è riuscito a proporre anche internamente all’azienda un seminario di questo tipo, l’incontro si è tenuto la settimana scorsa e il risultato è stato naturalmente un successo.

O' Professore

O’ Professore

Al termine della veloce presentazione ci siamo cimentati con l’esplorazione di un’idea, formando due squadre e lavorando in parallelo. Le squadre hanno percorso strade divergenti ma entrambe potenzialmente realizzabili.

Il risultato del pomeriggio di lavoro/svago

Il risultato del pomeriggio di lavoro/svago

Canvas, parola che vuol dire tutto e niente

Canvas in inglese vuol dire tutto e il contrario di tutto. Letteralmente significa tela, in pratica lo si può usare ogniqualvolta si definisce qualcosa in modo schematico. Il Business Model Canvas è stato solo uno dei canvas trattati, e sulla sua scia ne sono venuti fuori altri: il Product Canvas, il Value Proposition Canvas, e il Personal Business Model Canvas.

Business Model Canvas

Il capostipite della famigla, da una visione di insieme di tutto il contesto del business nel quale ci vogliamo lanciare comprendente il prodotto, i clienti, le relazioni con clienti/fornitori, le attività/risorse chiave, i costi e i ricavi.
Se ne parla in siti internet in italiano e in inglese, ma soprattutto in un libro molto bello, quel Business Model Generation, di cui non si può non consigliare l’acquisto considerato quanto è denso di contenuto, bello graficamente e piacevole da leggere.
Trattandosi di “schematizzazione di contesti di business” esiste tutta una letteratura di patterns ricorrenti dal quale possiamo prendere spunto per il nostro business, o che dovremmo conoscere per evitare di sbattere il muso per terra come è già successo ad altri nei secoli passati.

Product Canvas

Visione in dettaglio del blocco centrale e principale del BMC, quel Value Proposition che è evidentemente un po’ troppo fumoso per essere di una qualche utilità. Serve per sintetizzare quali saranno le caratteristiche principali del prodotto, il nome, lo scopo, come ne misureremo l’efficacia e così via. Forse si tratta dello schema più semplice da riempire nel momento in cui abbiamo in mente un’idea, ma è chiaramente anche il più “importante” (per quanto lo sono tutti) perché ci da velocemente un’immagine di come sarà il nostro prodotto, senza curarci del contesto.
BMG - Product Canvas

Value Proposition Canvas

Questo diagramma è quello con la forma più carina e “di design”, ma in realtà lo si sarebbe benissimo potuto disegnare in qualunque altro modo, perché il suo scopo altro non è che quello di mappare le esigenze e i desideri del cliente con le caratteristiche del prodotto che abbiamo intenzione di immettere sul mercato. Il cliente (o meglio un segmento della clientela a cui ci rivolgiamo) guarda al prodotto perché ha dei bisogni, e questo canvas dovrebbe servire a mappare le sue necessità con le soluzioni che il nostro prodotto gli offrirà. Se ci rendiamo conto già su carta che non riusciremo a dare al cliente tutto ciò di cui ha veramente bisogno probabilmente il nostro business sarà un fiasco.

Personal Business Model Canvas

Al suo interno racchiude il nome del genitore perché in questo caso il prodotto da vendere siamo noi, e se usiamo questo canvas significa che non abbiamo abbastanza “clienti” o che stiamo per immetterci in un nuovo mercato.
Con quest’ultimo schema andiamo un po’ “fuori dal somentado” perché in un certo senso abbiamo già il prodotto e si presume che lo conosciamo abbastanza bene dal momento che si tratta di noi stessi. Se siamo bravi nell’introspezione compilare questo foglio non è che ci darà poi molto, ma può essere comunque un utile esercizio specialmente se siamo disoccupati e dobbiamo scrivere un curriculum vitae o se pensiamo di non essere adeguatamente valorizzati con il nostro attuale lavoro.
BMG - Personal Canvas

Con chi

In generale quando si ha intenzione di produrre qualcosa e si vuole fare dell’analisi bisognerebbe fare gioco di squadra, e la squadra dovrebbe essere quanto più variegata possibile per competenze, attitudini, età, sesso e così via. Compilare un BMC in una squadra di quattro/cinque persone è un’esperienza stimolante e divertente, se si è di meno si rischia di andare un po’ troppo a singhiozzo e sicuramente potrà mancare qualche competenza, se si è in più il tutto potrebbe rischiare di finire in baraonda o con qualcuno che se ne sta zitto in disparte.
Farlo da soli può essere un po’ estremo ma secondo me non è da escludere, perché una volta prodotto qualcosa e stabilito che non è poi così campato in aria ci si può sempre ragionare di nuovo in compagnia.

Quando, come e perché

Abbiamo in mente l’app rivoluzionaria? Vogliamo provare a commercializzare i nostri centro-tavola al punto croce? Pensiamo di darci alla politica? In un certo senso ogni volta che vogliamo generare offerta di qualcosa e cerchiamo quindi della domanda stiamo generando un business, e fare un quadro della situazione compilando questi canvas può essere molto utile. Nella migliore delle ipotesi il nostro prodotto ne uscirà migliore, nella peggiore (ma nemmeno tanto) sposteremo la nostra idea dal cassetto al cestino perché è chiaramente una “minchioneria”.
Sebbene gli insegnanti cerchino di convincerci che ci sono dei modi “migliori” di compilare il Business Model Canvas, o qualcuno ci assicuri che è preferibile compilare prima il Product Canvas, dal mio punto di vista non c’è un modo giusto e uno sbagliato per lavorare con questi schemi. Si può partire dal prodotto o dal cliente, o dalle proprie caratteristiche produttive, e ciascun punto di partenza ci porterà inevitabilmente a risultati diversi.
Il mio consiglio quindi è: iniziate sempre con il capire dov’è che risiedono le nostre maggiori certezze o dov’è che abbiamo minor margine di manovra. Se il prodotto è già ben definito nella nostra mente tanto vale partire dal prodotto, se invece abbiamo giusto qualche traccia forse può avere più senso partire dal BMC, così da lavorare prima su una visione d’insieme di tutto il business che può aiutarci anche a definire il prodotto.

Di certo c’è che giocare con la carta e i pennarelli è sempre un piacere, e spendere qualche ora per fare un quadro della situazione su carta è un investimento da fare senza remore.

Quando tutto sembra perduto: git reflog

Un paio di giorni fa ho avuto modo di usare una delle funzioni più belle di git, e siccome non tutti la conoscono credo sia il caso di celebrarla un po’ perché mi ha salvato qualche ora di lavoro.
Piccola premessa: ho iniziato a mettere le mani su un progetto mai visto prima e il log di git era abbastanza ordinato, quindi per fare la mia parte ho fatto un branch per la funzione che dovevo aggiungere e avevo intenzione di fare un merge e push sull’origin al termine della modifica. Non sono ancora un utilizzatore di git esperto, quindi a volte faccio delle cavolate…

Ipotizziamo di avere un progetto già avviato con alcuni commit (nel mio esempio uno), e di voler aggiungere una funzionalità. Come consigliato dal galateo facciamo un nuovo branch, ci spostiamo su di esso, facciamo dei commit (possibilmente autoconsistenti e che non rompano niente) e concludiamo la modifica.
Git reflog - Preparazione

Arriva il momento di fare il merge. Ipotizziamo di aver sbagliato qualcosa, magari perché stiamo usando un tool grafico poco chiaro, e ci ritroviamo con un po’ di leggerezza a cancellare il branch con un bel "git branch -D nomebranch".
Apparentemente tutto il nostro lavoro è andato perduto e lo scoramento ci assale mentre dalla nostra bocca esce un fiume di bestemmie e parole sconce.
Git reflog - Cancellazione branch

Quando tutto sembra perduto ci ricordiamo di aver letto che con git non si perde mai niente, perché all’occorrenza esiste anche un log parallelo al principale a cui poter attingere nei momenti di difficoltà: il reflog.
Digitiamo "git reflog" e vediamo con nostro grande sollievo che i nostri commit fatti sul branch andato perso sono ancora tutti lì in memoria, e volendo possiamo recuperarli.
Un "git reset --hard HEAD@{index}" e come per magia ritroviamo nel nostro log principale tutti i commit che erano presenti nel branch tagliato per errore.
Git reflog - Ripristino commit

Siccome siamo precisi a questo punto non possiamo non domandarci “Ma i commit non li avevo fatti un un branch secondario? Come mai me li ritrovo sul master?”.
Infatti il reset hard fatto poc’anzi salva i commit ma li mette nel master perché non sono collegati ad alcun ramo, volendo si può far eseguire il ripristino su un ramo secondario, magari chiamandolo con il nome di quello tagliato erroneamente: "git branch nomeramo HEAD@{index}"
Git reflog - Ripristino ramo

La storia è importante e non va mai dimenticata. Git lo sa, e con il reflog ci fornisce uno strumento salvifico da utilizzare nei momenti più difficili.

Titanium Studio e GIT, integrato (a volte) è meglio

Sviluppatori: ognuno con le sue convinzioni e il suo credo

Gli sviluppatori mobile con Titanium si dividono in due scuole di pensiero: chi utilizza Titanium Studio e chi preferisce usare un ide meno pompato e la console. Io appartengo ancora alla prima categoria, principalmente perché mi districo male tra molte finestre e preferisco avere sempre tutto sotto controllo mentre lavoro. L’idea di passare a Sublime o Atom in combinazione eventuale con strumenti esterni mi ha tentato, ma ancora non ho raccolto gli stimoli sufficienti.

Il problema è che Titanium non è il solo strumento che contribuisca a dividerci in caste, perché anche GIT non scherza. I puristi conoscono tutti i comandi con relativi parametri a memoria e utilizzano soltanto la console, i pigri/smemorati come me si affidano a strumenti un po’ più “smart” e ricorrono alla console solo in casi di emergenza o come esercizio di memoria. Personalmente io uso alternativamente la console, il plugin integrato nell’ide e SourceTree, un gestore di repository GIT veramente ben fatto.

SourceTree, e GIT non sarà più così ostico

SourceTree, e GIT non sarà più così ostico

La I di IDE sta per “Integrated”…

Fatte queste distinzioni è ora di arrivare al dunque: perché questo articolo? Il punto è che non sarebbe male utilizzare nel proprio ambiente di sviluppo un plugin che ci aiuti ad avere sempre sotto controllo tutte le modifiche fatte ai nostri sorgenti. Eclipse ha degli showview integrati (History e Synchronize) con cui poter vedere lo storico e lo stato attuale delle modifiche, ma in Titanium questi non funzionano con GIT. Infatti l’ide Titanium Studio ha un suo plugin per GIT (com.aptana.git), che però si integra malissimo con Eclipse e secondo me è praticamente inutile.

Come guardare il dettaglio dei plugin installati

Come guardare il dettaglio dei plugin installati

Aptana Git, per la serie: meglio soli che mal accompagnati

Aptana Git, per la serie: meglio soli che mal accompagnati


L’amato/odiato Eclipse ha un suo plugin per gestire decentemente il repository GIT (EGit), ma non viene fornito con Titanium Studio e fa a cazzotti con quello installato di default.
Il mio consiglio è quindi quello di disabilitare il plugin di Aptana e utilizzare EGit, e ora vi mostro come fare.

Installazione e utilizzo di EGit su Titanium Studio

Punto 1: Per prima cosa conviene dire a Eclipse di non utilizzare più il plugin di Aptana per gestire i nuovi progetti GIT aggiunti nel workspace. Questa cosa la si fa dalla pagina delle preferenze di Eclipse.

Disabilitazione di Aptana Git per i nuovi progetti

Disabilitazione di Aptana Git per i nuovi progetti

Punto 2: Se volete usare su Eclipse un plugin non fornito di default (in questo caso EGit) bisogna installarcelo. La procedura è sempre la stessa e ne avevo parlato in modo un po’ più dettagliato su un precedente articolo (a proposito di SVN su Eclipse).

Installazione di EGit

Installazione di EGit

Punto 3: Nel caso abbiate già dei progetti che utilizzano GIT come VCS all’interno del vostro workspace questi continueranno a usare il vecchio plugin. Scollegateli da esso e fate in modo che usino il nuovo plugin.

Disconnessione di progetti esistenti da Aptana Git

Disconnessione di progetti esistenti da Aptana Git

Connessione di EGit ai progetti git precedentemente scollegati da Aptana Git

Connessione di EGit ai progetti git precedentemente scollegati da Aptana Git

Il Synchronize di Eclipse, uno dei miei strumenti preferiti del mio IDE preferito

Eclipse ha molte funzioni, ma una delle mie preferite e indipendenti dal VCS utilizzato (GIT, SVN, …) è la view Synchronize, che mostra l’elenco dei file modificati rispetto al repository (e all’origin nel caso del GIT) e da la possibilità di modificarli facilmente con una finestra di comparazione. Funzione fondamentale in un ambiente di sviluppo integrato degno di questo nome.
Titanium - Synchronize

Conclusioni

Si può usare un ide o qualunque editor di testo in combinazione con tool esterni, l’importante è avere sempre sotto mano tutte le funzioni di cui si ha bisogno. Titanium Studio per usare un eufemismo non è che sia proprio performante, ma è basato su quel mostro di configurabilità ed estendibilità che è Eclipse, conviene quindi sfruttare al meglio le sue peculiarità installando all’occorrenza ciò che manca.

Memoization: metti il turbo alle tue funzioni Javascript

La memoizzazione – da non confondere con memorizzazione – è una tecnica usata allo scopo di evitare che una stessa funzione, onerosa dal punto di vista computazionale, venga eseguita più volte con gli stessi valori. In pratica si fa in modo che il valore di ritorno corrispondente a certi parametri finisca in una sorta di cache, cosicché eventuali successive chiamate alla stessa funzione con gli stessi parametri non comportino delle nuove esecuzioni della funzione stessa.
In javascript questo simpatico giochetto si può implementare in un paio di modi, a seconda che la funzione accetti parametri oppure no.

Funzione senza parametri, caso più “semplice”

Ipotizziamo che nel nostro programma da qualche parte ci sia una funzione che non si aspetti alcun parametro in ingresso e che durante l’esecuzione del programma potrebbe dover essere eseguita più volte. In questo caso – non molto frequente ma nemmeno raro – mettere il risultato in una “cache” non ha proprio senso perché non si ha nemmeno una “chiave” con cui riandarlo a pescare. Si possono quindi sfruttare gli scope e il fatto che una funzione è un oggetto come tutti gli altri (e quindi memorizzabile in una variabile).

// funzione originale
var getSomething = function(){
  var something;
  something = {}; // logica onerosa
  return something;
};

// funzione modificata
var getSomethingMem = function(){
  var something;

  something = {}; // logica onerosa

  getSomethingMem = function(){
    return something;
  };
  return getSomethingMem();
};

Si ha una funzione anonima getSomething che esegue tutta una serie di calcoli onerosi e ritorna un risultato. Per farne il memoize è sufficiente – una volta eseguita la computazione e salvato il risultato in una variabile – assegnare alla variabile contenente questa funzione una nuova funzione che ritorni direttamente il valore calcolato. La variabile something è inclusa nello scope di questa nuova funzione “fasulla” getSomethingMem, e questa funzione dopo la prima esecuzione non farà altro che ritornare il valore calcolato la prima volta.

Funzione con parametri, la cache

Il “trucco” illustrato sopra non si può applicare al caso di funzione che si aspetta dei parametri in ingresso, ma la flessibilità del javascript ci permette di assegnare una cache a qualunque funzione.
Spiegarla a parole non è proprio semplice lascio quindi a voi il piacere di capirla, in fondo sono solo poche righe di codice.
In questo caso la “cache” è un modulo CommonJs, la sua funzione create prende in ingresso una funzione (ad esempio una list) e ritorna un oggetto avente una sua implementazione “estesa” con la cache della stessa funzione list, più eventuali altre funzioni di utilità.

var list = function(params){
  // logica onerosa, ma stateless e indipendente dal tempo
  return {};
};

list = require('Cache').create(list).get;
exports.create = function(f, params){
  params = params || {};
  
  var cache, get, reset;
  
  cache = {};
  
  get = function(){
    var key = JSON.stringify(Array.prototype.slice.call(arguments));
    if (key in cache){
      console.log('From cache: ' + key);
      return cache[key];
    } else {
      console.log('Not in cache: ' + key);
      return cache[key] = f.apply(this, arguments);
    }
  };
  
  reset = function(){
    cache = {};
  };
  
  return {
    'get' : get,
    'reset' : reset
  };
};

Detto che la funzione di memoize può essere implementata in vari modi (quella sopra è una versione modificata di una che trovai da qualche parte sul web), è chiaro che si possono trovare librerie che ci alleggeriscono del compito. Librerie -> Javascript -> ovviamente qualcosa c’è anche in Underscore.js.

In sintesi

È la memoization la cura per ogni male? Chiaramente no. Può essere usata sempre? No, la risposta è quasi sempre no quando in una domanda compaiono dei quantificatori universali come “ogni” o “sempre”…
Queste tecniche potrebbero risolvervi grossi problemi di prestazioni ad esempio in presenza di funzioni lente perché causa di molte letture su disco, a discapito di un maggior utilizzo della memoria, ma questo divario si riduce di molto se i dischi sono SSD.
In presenza di funzioni stateful (il male, almeno quando si usano linguaggi funzionali), chiaramente non si può pensare di bypassare l’esecuzione della funzione andando a pescare il valore in una cache, così come non si può fare troppo affidamento su una cache se i risultati cambiano allo scorrere del tempo (ad esempio perché le elaborazioni sono basate su dati aggiornati periodicamente).
Il caso limite è quello di una funzione molto complessa che fa molte query su un database i cui dati cambiano ma non troppo spesso. In un caso del genere il suo utilizzo ci potrebbe stare ma bisognerebbe implementare adeguate logiche di “pulizia” della cache dei risultati a ogni aggiornamento dei dati.

A usarla bene il vostro smartphone/tablet potrebbe anche spiccare il volo, ma facendolo con leggerezza i risultati delle vostre funzioni saranno sbagliati… “Da un grande potere derivano grandi responsabilità”.

UX, ATM e vestizione di bug

Qualche tempo fa ho avuto la fortuna di poter assistere a un talk di @rainwiz che mi ha un po’ liberato di alcuni pregiudizi che avevo riguardo ai miei colleghi designer, i quali si occupano solitamente di migliorare la forma dei prodotti software lasciandone pressoché immutata la sostanza. Io da parte mia l’ho sempre pensata alla Don Camillo, ovvero “una cosa è bella quando è di buona qualità e serve bene al suo scopo”, e ho sempre messo font/colori/immagini in secondo piano rispetto alla “ciccia”. Ebbene in quella lunga e interessante serata di novembre ho scoperto che gente molto in gamba, spesso ferrata in psicologia (o nel caso dello speaker antropologia), si occupa quasi interamente di raccogliere informazioni attraverso interviste e questionari cercando di alterare il meno possibile i loro oggetti di osservazione (di solito i futuri utenti dei nostri software).
Esistono UX engineers (UX sta per User eXperience) che più di abbellire la UI si preoccupano di capire come ragionano gli utenti, di sfruttare scorciatoie psicologiche per facilitarne il lavoro, di evitare tranelli mentali che potrebbero causare spiacevoli inconvenienti.

ATM, goal e dimenticanze

Vi era un tempo, nemmeno troppo lontano, in cui andando a prelevare contante la gente dimenticava la propria carta/bancomat nell’ATM. In molti si saranno chiesti il perché, visto che il processo di prelievo era perfettamente simmetrico – carta => pin => soldi => carta – finché probabilmente si sarà richiesto il parere di qualche esperto psicologo (o studente in psicologia, tanto basta), e l’arcano è stato svelato.

Sopra la sequenza originaria, sotto quella attuale

Sopra la sequenza originaria, sotto quella attuale


Il problema non era tanto nella smemoratezza degli utenti, quanto in una delle funzioni esecutive della nostra mente, e nel caso specifico in quella del mantenimento del gol/meta/obiettivo in memoria.
Il concetto è semplice: si va all’ATM con un compito (task) chiaro, il prelievo di contante, e la nostra mente focalizza l’attenzione su questo obiettivo; una volta che lo si è raggiunto l’operazione è terminata, e tutto il resto rischia di cadere nell’oblio. Guardando questo flusso dalla giusta angolazione, il ricordarsi di prendere la carta prima di andarsene sembra più un’eccezione alla regola che non il contrario. Vero che se si ha tempo e si è concentrati nello svolgimento del compito generalmente ci si ricorda, ma è proprio quando si è sovrappensiero che la mente lavora in automatico, e in queste occasioni un processo modellato non tenendo conto di questi aspetti di psicologia basilare può creare grossi problemi agli utenti, anche economici.

Restando in materia di goal un esempio diverso ma non troppo è secondo me quello dell’aperitivo al bar. Si va al bar per stare in compagnia, fare due chiacchiere e bere qualcosa, e prima o poi si paga. Gli obiettivi sono chiaramente due – lo stare in compagnia e il bere qualcosa – il pagare è soltanto un mezzo, ma dal momento che in ogni bar le regole un po’ cambiano (in alcuni si paga prima e in altri dopo, nel “nostro” capita di “segnare” e spesso il barista sa già cosa vogliamo), nella nostra mente lo schema non è ben definito, quindi questa se costretta a lavorare in automatico pensa solo a fare goal. Il tempo passa, si fa tardi e salutiamo, ecco che ci siamo dimenticati di pagare. Io da parte mia raramente mi dimentico di qualcosa, e a dispetto del detto “a pagare e a morire c’è sempre tempo” cerco sempre di pagare il prima possibile, eppure mi è capitato di essermene andato senza aver pagato, e l’ho fatto anche in posti diversi dal bar.

Sempre UX e psicologia, ma applicate alle casse automatiche invece che ai bancomat

Ieri sono andato a fare la spesa e per una volta, avendo tempo, ho provato a usare la cassa automatica. Tutto molto bello, con la doppia bilancia per evitare che la gente si “dimentichi” di passare qualcosa sullo scanner, il lettore di codici a barre fisso e manuale, il controllo umano in caso di acquisti di alcolici… riguardo a questo soggetto è doveroso aprire una parentesi, quell’uomo sembrava ad un passo dal tagliarsi le vene, credo che uno dei pochi lavori più brutti di quello di cassiera sia quello di addetto alla cassa automatica, chiusa parentesi.
Finito di passare gli articoli c’è da pagare, si preme l’apposito pulsante mentre si prende il portafogli e, guidati dalla voce che chiede l’inserimento di contanti o carta si procede con il dare in pasto i soldi alla macchina. Da un verso non li prende, dall’altro neppure, il lettore chissà perché sembra non funzionare. Eppure la voce continua a richiedere l’inserimento dei soldi…

Cassa automatica al momento del pagamento

Cassa automatica al momento del pagamento


Dopo un minuto circa passato a girare e rigirare la banconota incitato dalla solita impassibile voce decido di guardare di nuovo il monitor, distante quasi mezzo metro dal mangia soldi, e vedo che c’è scritto di selezionare il metodo di pagamento.
Lasciamo stare per un momento la mia distrazione a causa della quale ho perso di vista il monitor e non ho letto cosa dovevo fare, ignoriamo anche la voce registrata che mi richiedeva una cosa mentre il monitor me ne chiedeva un’altra, e torniamo alle funzioni esecutive. L’utilizzo della cassa automatica era per me un’operazione nuova, e l’ho svolta quindi seguendo le istruzioni e comportandomi all’incirca come fossi stato d’avanti a una cassiera (allo stesso modo ho tirato fuori la carta fedeltà a metà spesa giusto perché mi sono ricordato, forse quella vocina avrebbe dovuto dirmelo all’inizio, o forse me lo avrebbe detto alla fine, chissà…). Arrivato il momento di pagare ho tirato fuori i soldi e per la mia testa questo doveva bastare, forse sarebbe stato il caso di abilitare direttamente i vari lettori aspettando uno qualunque degli input e richiedendo istruzioni soltanto in caso di ambiguità (ad esempio sul tipo di carta). La cassiera a volte me lo domanda se voglio pagare con la carta, ma di solito il tenere in mano i contanti per lei è un messaggio abbastanza chiaro, ma non lo è stato per il software il tentativo di inserirli prima di avergli detto che lo stavo per fare. La user experience pensata dai designer è ottimale? Forse si può fare di meglio?

Di sicuro c’è che questa concezione di supermercato ai giorni nostri non ha più alcuna ragione d’essere, in futuro secondo me ci saranno supermercati molto più piccoli affiancati a grossi magazzini, le persone selezioneranno la merce da un monitor e se la ritroveranno in delle buste già pronta per essere ritirata. Oppure si prenderà all’ingresso soltanto un lettore di codici a barre e ci si muoverà per dei negozi pieni di monitor scegliendo la merce a colpi di scanner, per ritrovarsela alla fine già pronta. Forse la merce ce la consegneranno direttamente a casa. O forse non esisteranno più nemmeno i supermercati e si acquisterà tutto sul web con la possibilità di pagare un po’ di più per merce con scadenze più lontane e di meno per quelle a scadenza prossima. In questo modo si pagheranno meno stipendi per lavori avvilenti e inutili, si ridurrà il rischio di taccheggi, e soprattutto molti meno alimenti saranno buttati perché scaduti. Vedremo.
Per il momento diciamo che il lavoro di cassiera al supermercato non può e non deve sopravvivere, è disumano.

Trasformare potenziali bug in features lavorando di esperienza e fantasia

UX non è solo fare in modo che l’utente esegua il proprio compito nel modo più semplice e appagante possibile, ma anche il cercare di fornirgli a basso costo funzionalità realmente utili e ridurre il rischio di errori.
Sono buoni tutti a investire tempo e denaro per sviluppare funzionalità di un software, ma non tutti sanno riconoscere l’opportunità di sfruttare potenziali bug per arricchiere il proprio programma. Nel libro I 36 stratagemmi il quattordicesimo stratagemma consiglia di “prendere a prestito un cadavere per rifondervi lo spirito”.

Stratagemma 14 della strategia cinese: "that's a feature!"

Stratagemma 14 della strategia cinese: “that’s a feature!”


Niente meglio di un buon aneddoto per fissare il concetto, raccontato da un esperto sviluppatore di mia conoscenza. Costui doveva aggiungere un sistema di messaggistica istantanea al proprio software e, trovatosi di fronte alla possibilità di inviare messaggi a se stessi, era prossimo a togliere questa possibilità perché poteva essere interpretata come un bug. Ebbene non lo fece, ma piuttosto mascherò questo “effetto collaterale non voluto” in modo da farlo sembrare una scelta, una possibilità di dialogare con se stessi come scrivendo su un blocco note. E ai clienti l’idea piacque. Per inciso questa cosa è possibile anche sull’applicazione Messenger di Facebook, ma non su Hangout di Google.

Buoni propositi pasquali

Non solo modellando processi da automatizzare al computer bisogna tenere conto di come funziona la mente, anche nella vita di tutti i giorni conoscere qualche fondamento di psicologia non guasta e può aiutare a evitare colossali figuri di me..a. Faccio quindi voto solenne, e questo articolo ne è testimone, che quanto prima cercherò di leggere almeno un libro sull’argomento e di riflettere un po’ di più sugli aspetti psicologici del mio lavoro ma anche del mio agire. Sperando di non dimenticarmene (il goal oggi è pur sempre lo scrivere quest’articolo).