Ispezionare le cartelle private di un’app Android

La concorrenza: iOS

Quando si sviluppa un’applicazione per iOS controllare i dati della propria app su filesystem è tutt’altro che un problema, perché è possibile ispezionare i dati di ogni applicazione installata (in test) su ciascun simulatore, semplicemente con il Finder.
Il percorso di questi file è cambiato tra la versione 7 e la 8 di iOS, e ora i file si trovano su ~/Library/Developer/CoreSimulator/Devices/_DEVICE_UDID_/data/Container/Data/Application/_APPLICATION_ID_/....
Purtroppo gli id dei dispositivi e delle applicazioni sono delle sequenze di numeri e lettere tutt’altro che parlanti, ma basta capire come con Xcode è possibile ispezionare questi codici, o meglio ancora che è sufficiente stampare sul log della propria applicazione i percorsi interi e poi andarseli a guardare, e i dati delle nostre applicazioni mobile non avranno più segreti.

Il robottino verde è più timido

Quando si passa ad Android le cose si fanno più complicate. Per cominciare i dati possono essere salvati nella directory privata data/data/appid o in aree per così dire “pubbliche” ma sempre in cartelle con lo stesso nome dell’appid, che possono trovarsi nella root o in /Android/. E’ importante scegliere bene dove salvare i dati, perché quelli più “strategici” dovrebbero essere protetti il più possibile, mentre altri più di pubblico dominio sarebbe meglio lasciarli accessibili anche da applicazioni terze, per offrire maggiori funzionalità.
Detto che il similatore classico di Android è indegno di essere paragonato a quello di iOS, con l’arrivo di Genymotion anche gli sviluppatori Android si sono ritrovati con una valida alternativa ai dispositivi fisici, ma in questo caso l’accesso ai dati è più problematico rispetto a iOS.

Accesso fisico ai file da un dispositivo o da Genymotion

A differenza dei dispositivi Apple quando si parla di Android i file manager non sono utopia ma vengono installati di default o è possibile comunque scaricarsene di buoni senza spendere un centesimo.

Uno dei tanti file manager (gratuiti) su Android

Uno dei tanti file manager (gratuiti) su Android


Su Genymotion sarebbe possibile installare i Google play services per poi scaricarsi qualunque app presente sul market, ma se abbiamo bisogno solo di un file manager qualunque ce n’è già uno preinstallato.
Il file manager preinstallato su Genymotion

Il file manager preinstallato su Genymotion


Fin qui tutto semplice, e per prendere i file senza tanti giri strani è sufficiente condividerli, ad esempio con Dropbox. Ma come fare per andare a sficcanasare tra i file privati e/o a copiarsi tutti i file dell’app?

ADB, ovvero il ponte

ADB è un tool presente nell’sdk di Android con cui è possibile fare tante cose carine, tra cui copia di file, backup, esecuzione di query sui db sqlite delle varie app e chi più ne ha più ne metta.
L’eseguibile dell’Android Debug Bridge si chiama “adb” e lo si può trovare nella platform-tools interna alla directory di installazione dell’sdk Android.
L’sdk di Android può essere ovunque perché dipende da chi o cosa l’ha installato, ma in genere sta in:
/Users/username/Library/Android/sdk/ (Mac)
C:\Users\username\AppData\Local\Android\sdk (Windows)
perché questi sono i percorsi di default quando si installa Android Studio.

Alcuni comandi e limitazioni varie

Con l’adb si può:

  • visualizzare la lista dei dispositivi/simulatori disponibili: ./adb devices
  • collegarsi alla shell di un dispositivo/simulatore per eseguire operazioni su file system: ./adb -s device shell
  • una volta che si è dentro la shell si possono visualizzare le app installate: ls data/data

… e tante altre cose. Ma la cosa che ha me è servita di più è la creazione di un backup dell’app, perché purtroppo succede che la documentazione dell’sdk che stiamo utilizzando sia fallace e ci induca a utilizzare percorsi sbagliati per salvare e caricare i nostri database… e lo scaricarmi in locale una copia dell’applicazione è stato illuminante in questo senso.
Purtroppo se il dispositivo a cui ci colleghiamo è ancora “integro” (non ci siamo collegati con l’utente root) alcune operazioni ci saranno proibite per mancanza di permessi. Peccato.

Backup dei dati di un’applicazione

Stabilito che in uno dei dispositivi collegati e accesi (telefono o simulatore) c’è un’app con appid uguale a it.blabla.boh, per farne il backup è sufficiente eseguire il comando:
./adb backup -noapk it.blabla.boh
Appena eseguito sul dispositivo/simulatore viene richiesta una conferma con eventuale inserimento di password.

La richiesta di conferma (e password) all'esecuzione del comando di backup

La richiesta di conferma (e password) all’esecuzione del comando di backup


Il risultato è la creazione di un file backup.ab dentro la cartella platform-tools. Questo file è abbastanza rognoso, ma per decomprimerlo senza grandi patemi esiste un programmino chiamato Android Backup Extractor (abe) che può essere scaricato da qui e il cui progetto si può trovare su GitHub.
Il file creato da adb backup

Il file creato da adb backup


La decompressione del file .ab in un .tar (a sua volta decomprimibile normalmente) è cosa (in teoria) semplice:
java -jar abe.jar unpack backup.ab backup.tar [password]

A volte funziona tutto, a volte l’abe va in errore non si sa il perché. Potrebbe dipendere dalla versione di Android installata sul dispositivo/simulatore, a me con la 4.3 è andata liscia, ma quando ci ho riprovato su un altro computer non ce l’ho fatta… Il file .ab comunque può essere decompresso anche in altri modi, se così non ce la fate buona ricerca.

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à”.