un anno fa raccontavamo su questo stesso blog di come fosse possibile scrivere un’applicazione mobile utilizzando le tecnologie del web; in questi mesi non siamo stati con le mani in mano ma abbiamo messo in pratica quello che prima avevamo solo  teorizzato. abbiamo, infatti, avuto la fortuna di metterci alla prova su diverse piattaforme:

* monotouch
* appcelerator titanium
* phonegap
* oltre allo sviluppo nativo

dopo 12 mesi di lavoro possiamo raccontare la nostra esperienza.

sviluppo nativo: la nostra esperienza di sviluppo nativo è legata alla piattaforma android ed al linguaggio Java ma in due contesti abbastanza diversi. il primo lavoro è stato un piccolo “modulo” per la scrittura su stampanti portatili esposto alle altre applicazioni del sistema comprese le pagine del browser, realizzato per permettere creazione e stampa di biglietti a bordo degli autobus del nostro cliente roma marche linee. l’approccio intrapreso è stato quello di arrivare a basso livello “solo dove necessario”, creando una piccola app che espone le proprie funzionalità attraverso il meccanismo degli Intent ed invocare queste funzionalità direttamente da un’applicazione web utilizzata via browser.

l’altra esperienza tutt’ora in corso è legata allo sviluppo di una applicazione per l’utilizzo di opendata. Ii questo caso parliamo di un’applicazione “classica” nativa che utilizza pienamente l’SDK e gli strumenti offerti da google. lo sviluppo  sta procedendo un po’ a rilento, ma la cosa è legata probabilmente alla nostra non approfondita conoscenza del java e all’abitudine ai linguaggi più dinamici. d’altro canto l’utilizzo del framework ufficiale offre una quantità di letteratura e di “problemi risolti” da non sottovalutare. la cosa che ci è piaciuta molto è la disponibilità di un framework di test rodato come junit integrato nell’SDK che permette di iniziare a testare il proprio codice “senza attriti”.

PRO:
sfrutta a pieno le caratteristiche piattaforma
permette di andare a fondo su qualsiasi problema
comunità di sviluppo molto estesa
unit test framework ben integrato
CONTRO:
non multipiattaforma
sviluppo meno rapido

monotouch. l’esperienza con monotouch è stata molto positiva ed è legata allo sviluppo di un software complesso di classe enterprise. quello che offre la piattaforma monotouch è un layer leggero di astrazione sopra le API native della piattaforma non nascondendone le peculiarità. separando bene la logica di business da quella di interfaccia è possibile condividere il core della propria applicazione su praticamente tutte le piattaforme su cui è disponibile il runtime di mono (android, IOs, windows phone, windows e linux). il vantaggio principale è legato alla possibilità di utilizzare tutta una serie di strumenti e librerie offerte dal completissimo framework .NET, con un linguaggio moderno ed elegante come C#. la piattaforma non è comunque esente da problemi: l’utilizzo di caratteristiche avanzate del linguaggio ci ha fatto riscontrare alcuni bug che hanno creato non pochi grattacapi.

PRO:
cross platform
framework che copre moltissime esigenze
C# ovunque (se vi piace C#)
CONTRO:
C# ovunque (se non ti piace C#)
alcuni bug di gioventù
per ottenere il cross-platform la user interface va riscritta

sviluppo titanium. titanium appcelerator è stata la prima esperienza mobile affrontata da e-xtrategy, per lo sviluppo di un’applicazione di domotica: seavdomus.  appcelerator è un framework per la creazione di applicazioni mobile cross-platform (iOS, Android e Blackberry) sopra il quale si sviluppa in javascript. l’utilizzo di questo linguaggio, unito a buone tecniche di programmazione, ha permesso il raggiungimento di un importante risultato: strada facendo è emersa la necessità di una web app evoluta che replicasse ed estendesse le funzionalità dell’applicazione mobile, che è stata realizzata riutilizzando gran parte del codice scritto per i dispositivi mobile, nonostante la natura completamente differente dell’applicazione. il vantaggio principale di titanium è la possibilità di scrivere con un solo linguaggio per diversi dispositivi mobile, utilizzandone al contempo i controlli nativi della piattaforma di destinazione. qualora il framework offerto da titanium non sia sufficiente, è possibile estenderlo, scrivendo moduli custom direttamente in codice nativo (in questo caso, ne va scritto uno per ogni piattaforma).

PRO
con poco codice si ottengono molti risultati (essendo un framework)
cross platform
controlli nativi in base alla piattaforma di destinazione
javascript ovunque (se ti piace Javascript)
CONTRO:
javascript ovunque (se non ti piace il Javascript)
alcuni bug di gioventù
per un corretto cross-platform la UX va comunque rivista e non mancano
gli aggiustamenti da fare

sviluppo phonegap. phonegap è la soluzione che fa più uso delle tecnologie web e proprio per questo è anche quella che permette il raggiungimento di più piattaforme possibili (iOS, android, windows phone, blackberry, webos, symbian). e’ infatti interamente pensato per sviluppare in HTML, CSS e javascript, tramite l’utilizzo di una web view che fa da ponte con le funzionalità del dispositivo. la nostra esperienza con questo tool si lega allo sviluppo di un’applicazione mobile/tablet in ambito wealth management e finanza .accoppiata all’utilizzo del framework jquery mobile è possibile ottenere un look & feel simil-iphone, anche se è possibile disegnare la propria interfaccia a piacimento e indipendetemente dai controlli nativi. questo è un vantaggio perchè possiamo disegnare una nostra interfaccia custom e farla girare allo stesso modo su tutti i device, ma anche uno svantaggio perchè ogni controllo va disegnato e gestito interamente da noi, non possiamo far affidamento ai controlli nativi e del dispositivo. va tenuto conto delle prestazioni: l’utilizzo di una web view limita la responsività dell’interfaccia, è quindi importante tener presente che non è adatto per applicazioni che fanno uso di effetti grafici. “impacchettare” è la parola d’ordine per questo tool: il suo principale vantaggio è infatti la possibilità di rinchiudere web site e servizi esistenti in un’applicazione mobile, oltre al raggiungimento di un parco dispositivi veramente ampio. non mancano i problemi di giovinezza ed i malfunzionamenti, ma le promesse sono molte.

PRO
cross platform spinto
sviluppo tramite tecnologie già note da chi lavora su web (html, css, js)
riutilizzo elevato del codice
javascript ovunque (se ti piace Javascript)
Interfaccia in HTML/CSS (se siete abituati a lavorare in questo modo o se nel team c’è alessandro violini)
CONTRO
l’accesso alle funzionalità del device non è completissimo
javascript ovunque (se non ti piace il Javascript)
instabilità delle API e documentazione poco affidabile
prestazioni
interfaccia in HTML/CSS (se non siete abituati a lavorare in questo modo)

la soluzione

come era facilmente prevedibile non esiste, la soluzione ma ogni piattaforma ha i suoi pregi e suoi difetti, spesso soggettivi e che dipendono dal team che si trova ad affrontare il progetto. quello che ci sentiamo di affermare però è che per poter scegliere la soluzione migliore in base al contesto ed ai vincoli di team e progetto è importante conoscere e sperimentare tutto quello che oggi c’è a disposizione. nel nostro caso particolare viste l’esperienza, le peculiarità del nostro team e non ultima la passione per il linguaggio javascript, l’utilizzo di titanium appcelerator e phonegap sono privilegiati rispetto alle altre soluzioni.

come si è visto le tecnologie utilizzate soffrono tutte di problemi dovuti alla giovinezza ma è evidente l’impegno che le varie community stanno mettendo per migliorare e renderle mature. Pochi giorni fa è stata rilasciata la versione 2.0 di appcelerator titanium e phonegap dopo l’adozione del progetto opensource cordova si stà riorganizzando per poter offrire rilasci frequenti ed incrementali.

inoltre l’esperienza fatta ci permette di dire che il vero cross platform non esiste, e questo non perché non è tecnicamente possibile, ma perché soprattutto a livello di user experience non è corretto sviluppare nello stesso modo un’applicazione che deve girare su sistemi diversi perdendo le peculiarità dell’una o dell’altra. quindi ben vengano framework e tecnologie che semplificano il riutilizzo del codice cross platrform, ma attenti a non sottovalutare l’UX.

se vuoi parlarne ci vediamo al jsday e al whymca

lorenzo, emanuele e giorgio

da un po’ di tempo a questa parte gestiamo la priorità dei nostri task attraverso l’utilizzo di una kanban board. ma che cos’è una kanban board ? vi rimandiamo alla breve ma efficace definizione del nostro coach, che può anche vantare il merito di aver introdotto questo strumento nella nostra azienda.

il kanban, lo scrivo brevemente a beneficio dei neofiti, è sostanzialmente una lavagna dove viene tracciato secondo poche ma ben determinate regole lo stato dei diversi task, abilitando il team ad una modalità di lavoro

1. concorrente, dove sono ridotti al minimo gli stati di attesa per svolgere il proprio lavoro
2. pull, dove si annulla la necessità di una figura responsabile dell’erogazione del lavoro da svolgere
3. trasparente, dove ognuno sa e può sapere cosa sta facendo l’azienda nel suo insieme in un dato momento.

abbattimento della burocrazia, trasferimento del controllo verso il basso e tracciamento di tutte le attività sono il cuore di questa soluzione.

effettivamente, abbiamo percepito i vantaggi citati da jacopo, vantaggi tangibili sin da subito ma ancora migliorabili. perché ?

i nostri problemi

perché nella prima introduzione di questo strumento ne andavamo a forzare lo scopo stesso: tracciare lo stato del sistema. provenivamo infatti dall’utilizzo di pivotal tracker, un ottimo servizio online per la gestione di user stories tra i vari progetti; ci siamo trovati quindi a “duplicare” lo stato del nostro sistema: le storie su pivotal, le storie sulla lavagna. si può intuire che, quando l’ambiente è rilassato, siamo tutti bravi e volenterosi nel tenere allineati i due strumenti, strumenti che però dovrebbero supportarci quando il carico del nostro sistema azienda è al massimo e che guarda caso andavano a fallire proprio in questo: arrivati al punto di stress viene a mancare la disciplina nel mantenere i 2 stati coerenti e la motivazione più diffusa solitamente recita “non ho avuto tempo, ho messo la storia di là”.

le conseguenze potete immaginarle.

la nostra soluzione

ma allora ? buttiamo via il kanban o non usiamo più il tracker online ? entrambe le soluzioni ci hanno aiutato tanto, perché doverne cestinare per forza una ?

pivotal è ottimo nel gestire le user stories di singoli progetti: calcolo della velocity, burn down charts, stime sulle scadenze via via più precise ad ogni iterazione e tutta una serie di feature che una volta introdotte difficilmente non si dirà “ma come facevamo prima senza?”. di contro non permette la schedulazione e la gestione contemporanea di più progetti: ognuno è un’isola a se stante ed anche se stiamo cercando in tutti i modi di abbassare il nostro wip, l’orizzonte del monotask è ancora un obiettivo a tendere.

il kanban ovvia proprio a questo problema: non è più necessario aprire uno ad uno tutti i progetti su pivotal per conoscere chi e su cosa sta lavorando ed a che punto è, basta un colpo d’occhio alla lavagna, vedere lo stato dei cartellini ed il gioco è fatto.

alla luce di queste poche ma importanti considerazioni, abbiamo capito che il problema non era l’esclusività di uno strumento rispetto all’altro, ma il fatto che i due lavoravano su piani differenti: se anche pivotal fosse stato cartaceo, il nostro cartellino riguardante una storia sarebbe stato uno ed uno soltanto, senza più problemi di allineamento perché o si trova nel backlog del kanban (suddiviso per progetti, che è proprio pivotal) o si trova in una qualsiasi altra lane (started, finished, delivered, accepted), ma, ripeto, in un punto soltanto.

se la cosa vale per il cartaceo, a maggior ragione vale per il digitale, ed è per questo che il 13 giugno abbiamo organizzato la “pivotal night”, un evento il cui scopo è stato creare un kanban digitale che accedesse direttamente ai cartellini di pivotal, tramite le sue api, e che ci avrebbe permesso finalmente di risolvere la questione

per uno strumento agile, ci vuole una metodologia agile!

visto che abbiamo tutti gli ingredienti, perché non tentare l’utilizzo di una modalità agile al 100% per lo sviluppo di questo progetto ? vi raccontiamo com’è andata la pivotal night, e le buone pratiche che abbiamo potuto sperimentare direttamente.

iteration meeting, utilizzo di un vocabolario comune e pair programming

per prima cosa abbiamo iniziato la serata con un briefing, dove tutto il team era riunito: un iteration meeting. le veci del cliente sono state fatte da lorenzo, in questo caso è un progetto interno e non c’è un vero e proprio cliente, per cui l’accettazione/rifiuto delle feature sviluppate è stato fatto dal product owner.

in questa fase abbiamo definito gli obiettivi della nostra iterazione, li abbiamo tradotti poi in user stories ed ordinate secondo il contributo in termini di valore che avrebbero apportato al nostro progetto.

oltre a ciò abbiamo definito un vocabolario comune a cui tutto il team doveva attenersi, sia per comunicare con gli altri membri, sia per scrivere codice.

• dashboard: il nostro kanban digitale
• panel: la singola lane, o corsia, che compone il kanban
• widget: il singolo cartellino che viene appiccicato nelle corsie e che rappresenta una user story

ci siamo poi dati una regola di comunicazione quando c’era la necessità di coniare nuovi termini ed aggiungerli al vocabolario, dando a lorenzo la responsabilità di gestire la concorrenza tra i pairs.

alla fine dell’iteration meeting abbiamo organizzato il team in coppie, ciascuna delle quali responsabile di una determinata area di sviluppo:

• lorenzo / alessandro: grafica e montaggio, supporto alla comunicazione
• daniele / emanuele: programmazione lato client
• giorgio / riccardo: programmazione lato server

condivisione e monotask

tutto il team ha lavorato su un unico progetto, ogni membo era a conoscenza dello stato dei lavori e non c’era nessuno di responsabilità. la visione è stata rovesciata: non più un comportamento individualistico, dove il responsabile punta al successo dei propri progetti, ma una visione comune, dove si vince e si perde tutti quanti insieme.

se, per quanto appena detto, la condivisione delle informazioni e del lavoro è importante, lo è di conseguenza tenere basso il numero di progetti aperti concorrentemente in azienda, sia per non avere cali d’attenzione, sia per non disgregare il team. l’attenzione è infatti la risorsa più limitata di cui il cervello umano dispone: fare più cose contemporaneamente, o passare frequentemente dall’una all’altra, porta ad una probabilità di errore più elevata, oltre che ad un allungamento dei tempi di sviluppo (ai tempi necessari per lo svolgimento dei task, vanno sommati anche quelli per il cambio di contesto, che non sono trascurabili).

non dimentichiamo infine che se il work in progres (wip) è basso il valore attualmente immobilizzato dall’azienda per produrne dell’altro è necessario ma non eccedente. questo significa che se interrompessimo il sistema in questo momento, la quantità di lavoro parzialmente svolto, e quindi da buttare, è inferiore.

il nuovo kanban è pronto

terminata la serata, siamo usciti dai nostri uffici soddisfatti del lavoro svolto, stanchi ma rilassati, soprattutto divertiti e con il nostro nuovo kanban pronto all’uso. la lavagna cartacea dopo 2 giorni è stata dimenticata e dopo una settimana dismessa. i problemi di allineamento sono stati eliminati.

lo strumento è certamente ancora molto giovane ed abbiamo già previsto nuove user stories per migliorarlo, ma visto quanto è già in grado di aiutarci, ci viene da dire che l’esperimento è decisamente riuscito

giorgio

phing è un’applicazione di build project o build tool basato su apache. è molto flessibile e può essere usato per molte funzionalità, con PHPunit e simpletest, trasformazioni di file, operazioni su file system, esecuzioni SQL, operazioni CVS/SVN, strumenti per creare pacchetti pear e altro ancora. qui potete trovare altre informazioni su phing.

il nostro utilizzo di questa applicazione è quello di snellire alcune procedure standard che effettuiamo durante le nostre operazioni con il repository. principalmente (per ora) questa applicazione, grazie ad un file build.xml che accompagna ogni progetto, esegue operazioni sul database permettendoci di aggiornarlo automaticamente dopo ogni update, o esportarlo (in struttura e dati) in modo rapido per essere “committato” in modo da aggiornare il repository.

vediamolo un po’ più nel dettaglio: il file build.xml viene utilizzato da phing per compiere operazioni in maniera automatica. dentro il file build.xml vengono definite delle macro-operazioni dette target, ciascuna delle quali è composta da una o più task, che possono essere operazioni tra le più disparate: dalla connessione SSH all’esecuzione di un comando da terminale.

nel nostro caso abbiamo creato due target fondamentali per coadiuvare la continuous integration:

• target build
• target make-sql

il target build si occupa di leggere i dump del database salvati su file e di importarli, oltre a varie ed eventuali operazioni dipendenti dal progetto (come la cancellazione di file temporanei, l’impostazione dei permessi di scrittura su determinate cartelle ed altri task che possono essere automatizzati al fine di rendere funzionante il progetto sulla macchina locale).

il target make-sql è il suo duale: se il primo si occupa dell’importazione del database, il secondo si occupa dell’esportazione. se lo sviluppatore ha bisogno di inviare al repository le proprie modifiche al database, lancerà il comando e successivamente eseguirà una commit dei file aggiornati.

un requisito: pear

per installare phing abbiamo bisogno del comando pear. nelle varie distribuzioni linux esso viene solitamente fornito di default quando viene impostato un ambiente LAMP, idem per machintosh che di solito è incluso negli ambienti di lavoro come ad esempio MAMP.

qualora si utilizzasse zendserver bisogna utilizzare l’eseguibile /usr/local/zend/bin/pear, per averlo sempre disponibile senza dover risalire ogni volta al path originale. Basterà creare un link simbolico dentro /usr/bin in questo modo:

sudo ln -s /usr/local/zend/bin/pear /usr/bin/pear

nota:
gli utenti linux con zend server troveranno tutti gli eseguibili dentro la cartella /usr/local/zend/bin
gli utenti machintosh con MAMP troveranno il comando pear dentro la cartella applications/MAMP/conf/php/bin – diversamente è possibile scaricare Pear separatamente in tal caso la cartella pear sarà sotto applications/

installazione di phing

per prima cosa bisogna registrare il canale di phing:
sudo pear channel-discover pear.phing.info

successivamente basterà eseguire il comando
pear instal phing/phing

a questo punto si suggerisce di creare un link simbolico per avere phing come comando di sistema.

ecco un esempio del file build.xml (formato zip).
e voi, come utilizzate phing?

alessandro e giorgio

uno dei tool più utilizzati per effettuare performance test è apachebench. sviluppato da apache, apachebench è un command line tool di semplicissimo utilizzo che permette di eseguire un determinato numero di richieste http ad una determinata pagina web.

possiamo utilizzarlo da linux, windows e mac e possiamo testare un server web sia locale che remoto. vengono fatte chiamate http standard quindi è possibile testare sia web server apache che di altro tipo. la configurazione ideale  è quella di avere un client da cui lanciare i test e un’ottima connessione verso il server (rete locale). se tra client e server c’e’ di mezzo una connessione internet, probabilmente il collo di bottiglia sarà quello.

possiamo effettuare il primo semplice test tramite il comando:

ab -n 100 -c 5 http://www.miosito.it/home.html

dove:

-n 100: ab invierà 100 richieste http alla pagina home.html di www.miosito.it
-c 5 : 5 sarà il numero di richieste contemporanee che ab invierà

ab ritornerà un output di questo tipo

——————————————————————————
Server Software:        Apache/2.2.16
Server Hostname:        www.miosito.it
Server Port:            80

Document Path:          /home.html
Document Length:        1144 bytes

Concurrency Level:      5
Time taken for tests:   0.239 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      133500 bytes
HTML transferred:       114400 bytes
Requests per second:    418.98 [#/sec] (mean)
Time per request:       11.934 [ms] (mean)
Time per request:       2.387 [ms] (mean, across all concurrent requests)
Transfer rate:          546.23 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    5   4.3      4      26
Processing:     1    7   5.2      6      29
Waiting:        0    4   4.8      3      28
Total:          3   12   5.3     11      31

Percentage of the requests served within a certain time (ms)
50%     11
66%     12
75%     13
80%     14
90%     16
95%     28
98%     31
99%     31
100%     31 (longest request)
——————————————————————————

naturalmente per test più attendibili occorre aumentare il numero di richieste e ripetere il test più volte modificando il numero di richieste contemporanee. ovviamente testare una pagina html statica non ha molto senso ma, se il test viene fatto su uno script lato server ad es php, è possibile valutare il comportamento del server in presenza o meno di sistemi di caching.

nel caso in cui dovessimo testare un script che riceve due parametri in post (ad es user e pass) per effettuare il login alla nostra applicazione web, ci vengono in aiuto i flag -p e -T, ed il comando da lanciare diventerà:

ab -n 100 -c 10 -p postfile.txt -T application/x-www-form-urlencoded http://www.miosito.it/login.php

simuleremo 100 richieste di login con le credenziali di accesso specificate nel file postfile.txt in questo formato:

user=prova&pass=prova

un’altra opzione di ab che può essere molto utile è rappresentata dal flag -e

ab -n 100 -c 10 -p postfile.txt -T application/x-www-form-urlencoded -e output.csv http://www.miosito.it/login.php

che oltre all’output stampato a schermo, creerà un file comma separeted che conterrà l’avanzamento percentuale e in millisecondi delle richieste effettuate.

esistono anche altre opzioni per le quali vi rimandiamo al manuale di ab

buon test
daniele

da più di un anno abbiamo adottato il manifesto agile all’interno di e-xtrategy. dopo l’esperienza del #fagg.it09,  abbiamo iniziato ad imparare e sperimentare le metodologie agili sempre guidati dal nostro coach jacopo romei.  inoltre da quasi un anno partecipiamo attivamente a XPug marche, avendo l’occasione di metterci in discussione e confrontare le nostre esperienze con altri professionisti.

proprio grazie a XPug marche, abbiamo potuto partecipare a questa esperienza che ha preso vita qualche settimana fa, un campo scuola di tre giorni in full immersion nelle pratiche del manifesto agile in una cornice rilassata dell’entroterra marchigiano in cui undici professionisti dalle diverse specializzazioni guidati dal coach jacopo romei hanno simulano la realizzazione di un progetto software attraverso l’utilizzo di extreme programming.

riassumiamo e citiamo alcune testimonianze e punti di vista in merito da parte di due partecipanti:

considerazioni di lorenzo massacci:

“perché vieni al campo scuola sulle metodologie agili?” mi ha chiesto jacopo almeno un paio di volte prima del csma10. in effetti dopo aver partecipato al fagg.it 09 (che trattava in sostanza gli stessi argomenti) poteva sembrare una ripetizione.

la mia risposta sta nella metafora utilizzata da lui stesso quando mi ha spiegato in cosa consiste il suo ruolo di coach, non ricordo le parole esatte ma il concetto era  questo: per imparare a giocare bene a calcio serve un allenatore, ma anche alessandro del piero (che ha esperienza e bravura) ha un allenatore che lo aiuta ad ottenere il massimo dal suo talento.
dopo questi mesi in cui ho letto libri, partecipato a conferenze e sperimentato sul campo posso affermare con certezza che per trarre beneficio dalle metodologie agili serve molto allenamento ed un team di sviluppatori di qualità e quindi quale migliore occasione del campo scuola per “allenarmi” e mettermi a confronto con “sviluppatori di qualità” come quelli dell’xpug marche.

inoltre alcune perle come provare praticamente il TDD (test driven development) in pair programming con jacopo o la discussione nata studiando il grafico del software feedback loop non hanno prezzo

considerazioni di alessandro violini:

nonostante avessi partecipato già un anno fa alla formazione di jacopo sulle metodologie agili ho trovato il campo scuola molto utile. in primis il sentirsi ribadire certi concetti dopo un anno di esperienza o “tentata” applicazione è stato molto utile anche perché il mio bagaglio di domande era mutato inevitabilmente e anche alcuni approcci alle metodologie stesse. in secondo luogo è stato molto utile avere anche le testimonianze e le questioni di altre persone che vengono da altri ambienti e da altre specializzazioni ma che spesso incappano nei stessi problemi o dubbi. terzo, in questo campo scuola c’è stata anche una parte pratica che un anno fa non venne focalizzata. Interessante osservare come lo sviluppatore, qualunque sia il linguaggio, si approccia alla soluzione del problema partendo dai test. stesso punto di vista che potrebbe essere applicato nel mio markup.

in fine, ma non per importanza, questa tre giorni mi ha illuminato su vari aspetti di un progetto in fase di avvio e progettazione. come le varie figure professionali si uniscono nella fase di user stories e plasmano il progetto che verrà realizzato. come il problema del design e della user experience viene “parallelizzato” il più possibile alle altre attività tecniche di codice grazie a piccoli accorgimenti e soprattutto, come l’agile insegna, grazie ad un approccio mentale diverso. questa parte è spiegata e discussa molto bene in un post di ilaria mauric che ha condiviso con noi questa esperienza.

cogliamo l’occasione anche per segnalare un bel articolo del nostro coach jacopo romei che racconta le ultime attività fatte insieme:

sono di ritorno da una splendida due giorni passata lavorando con i ragazzi di e-xtrategy pensata per svolgere una retrospettiva su un progetto appena concluso, che ho avuto modo di seguire sin dall’inizio. Inutile dire che l’esperienza è stata formativa per me almeno quanto lo è stata per loro, che mi offrono sempre grande fiducia e libertà di svolgere le nostre analisi, senza sovrastrutture inutili, senza pregiudizi e senza la pretesa di dover nascere imparati, né io né loro. (leggi tutto l’articolo di jacopo)

lorenzo

che cos’è la continuous integration ?

martin fowler nel suo articolo spiega:

continuous integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

da queste poche righe si apre la finestra verso un mondo: fowler non parla di strumenti o tecnologie, bensì di pratica.

il problema dell’integrazione non è banale: quando due o più sviluppatori lavorano contemporaneamente sullo stesso progetto non è raro che, al momento di mettere tutto insieme, si presentino problemi come conflitti o incompatibilità. troppo spesso si assiste allo scenario in cui la data di consegna al cliente è vicina  ed il software è più o meno pronto: << manca solo l’integrazione finale e gli ultimi fix >>, si direbbe, così facendo però solitamente ci si imbuca in un tunnel dentro il quale difficilmente si farà un bel viaggio, ma soprattutto sarà impossibile conoscerne a priori la lunghezza.

i bug e gli imprevisti sono per definizione non stimabili, né in numero né in complessità di risoluzione: come pretendere di stimare un tempo di integrazione, quando non si ha nemmeno una predizione a livello locale dei problemi emersi ? siamo finiti nel tunnel, nell’integration hell: la scadenza è sempre più vicina e non abbiamo idea di quando il software sarà correttamente funzionante. lo stress nel team aumenta con l’avvicinarsi della deadline, si rimane in ufficio fino a tardi e la stanchezza ed il malumore accumulati portano inevitabilmente all’introduzione di nuovi bug per risolvere quelli precedenti.

è proprio nel momento di mettere tutto insieme che la continuous integration interviene: l’integrazione del software non dovrebbe avvenire alla conclusione del processo di sviluppo, in cui tutti i problemi vengono identificati e risolti in una sola volta, ma dovrebbe essere parte di questo processo ed intervenire continuamente. la motivazione di ciò è semplice: rendere questo processo continuo limita il numero e la gravità degli errori rilevati, perché effettuare piccoli cambiamenti ed integrarli subito significa dover correggere al più bug recenti e non interi moduli dipendenti da anomalie introdotte molto tempo indietro e mai rilevate.

vediamo ora le pratiche fondamentali che ci permettono di fare continuous integration correttamente e come esse influenzeranno il nostro processo di sviluppo.

utilizzare un version control repository

l’utilizzo di un sistema di controllo di versione come subversion, git o CVS è il primo mattone con il quale costruire il nostro ambiente di continuous integration. tralasciando le differenze che i vari sistemi di controllo di versione hanno tra loro, è di fondamentale importanza avere un “repository” che permetta di gestire e monitorare i cambiamenti che avvengono sulla nostra code base. in questo modo si ha inoltre la possibilità di effettuare rollback dei cambiamenti: tramite strumenti di questo tipo infatti viene tenuta traccia della storia di ogni file.

nel repository deve essere presente tutto il necessario

non meno importante è l’avere tutto il nostro software, compresi framework, librerie e dipendenze esterne, all’interno del nostro repository: esso dovrà fungere da unica fonte del codice ed il nostro software dovrà essere in grado di funzionare solamente con quello che vi è contenuto, senza interventi esterni o aggiunte manuali.

eseguire una “commit” almeno una volta al giorno

come regola empirica, ci si impone di inviare il proprio lavoro al repository almeno una volta al giorno, anche se è vivamente consigliato puntare ad un numero di integrazioni maggiore. questo è necessario per rispettare il principio dei piccoli cambiamenti precedentemente introdotto. naturale conseguenza di ciò è la suddivisione del proprio lavoro in piccoli task atomici, che favorisce inoltre la scrittura di un codice più snello, pulito e mediamente privo di inutili complessità. in una sola parola, rispettare il KISS principle.

automatizzare le build

il processo di build non è solo la compilazione del codice (che non sempre avviene, come ad esempio nel linguaggio PHP) ma significa compiere un determinato numero di azioni che permettono al software di essere correttamente “costruito” e reso funzionante. rendere questo insieme di passi automatico attraverso un singolo script di building (come ant o phing) porta con sé vari vantaggi. primo: limita l’intervento umano e di conseguenza la probabilità di errori ed omissioni (lo sviluppatore lancia un singolo comando “build”). secondo, ma non meno importante: la riproducibilità ottenuta che permetterà a tutti gli sviluppatore di eseguire gli stessi passaggi in maniera identica (a meno di eventuali parametri di configurazione) mitigando la famosa, odiata frase “but it works on my machine”.

self testing build

non si fa continuous integration senza scrivere test automatici. tali test devono essere inoltre inglobati nei build script. a build completata lo sviluppatore conoscerà il risultato del proprio lavoro e solo tramite test automatici sarà in grado di averne confidenza sulla bontà. non è pensabile eseguire tali test manualmente perchè inevitabilmente qualcosa prima o poi verrà omesso, soprattutto nel modello di sviluppo che stiamo introducendo, in cui il software viene integrato (e quindi necessita di essere ritestato) ad ogni cambiamento.

è facile dire “il modulo b non necessita di essere testato perché ho modificato solo il modulo a” ma quante volte, nella realtà, sono emersi problemi derivanti da certe assunzioni? i test automatici sono la nostra rete di salvataggio e sono perfettamente riproducibili: ad ogni build ritesteranno tutte le funzionalità per cui sono stati scritti, più velocemente e più affidabilmente di qualsiasi sviluppatore o team, anche il più volenteroso, veloce e competente. nessuno riuscirà mai ad eseguire un gran numero di volte la stessa batteria di test senza ogni volta introdurre piccole differenze, soprattutto a fine giornata, quando la stanchezza si fa sentire. i build script, invece, non si stancano, usiamoli.

eseguire delle build private nelle workstation locali

ogni sviluppatore dovrà scaricare dal repository l’ultima versione del software che sta sviluppando. a questo punto lavorerà nella propria macchina locale, effettuando i cambiementi necessari per il proprio lavoro. una volta terminati dovrà effettuare la build del software sulla propria workstation ed osservarne i risultati. se tutto funziona correttamente, prima di inviare il proprio codice al repository, scaricherà da questo gli eventuali cambiamenti effettuati nel frattempo dagli altri sviluppatori e rilancerà di nuovo la build. se tutto va a buon fine, è stato fatto un primo passo verso l’integrazione: i propri cambiamenti sono stati integrati ed è possibile aggiornare la code-base eseguendo la “commit”.

non inviare codice difettoso al repository

in caso di fallimento dei test durante la build locale lo sviluppatore dovrà correggere i malfunzionamenti e rieseguire la build fino alla risoluzione dei problemi. non potrà, in nessun caso, inviare il proprio lavoro al repository se i test non certificano che esso è correttamente integrato.

in questo modo si minimizza la probabilità di avere software non funzionante nel repository: la copia “rotta” resterà confinata nella macchina dello sviluppatore che si occuperà di sistemarla.

eseguire una build di integrazione ad ogni cambiamento

ogni volta che il repository viene aggiornato con nuovi cambiamenti, il codice necessita di essere ritestato. successivamente alle build private, si eseguono quindi delle build di integrazione, che devono essere effettuate su di una macchina dedicata, che riproduca il più fedelmente possibile il vero ambiente di produzione. è importantissimo, inoltre, che questa ultima macchina sia priva di dipendenze e librerie spurie che non provengano direttamente dal repository: in questo modo ci si accerta che il lavoro dello sviluppatore sia ancora riproducibile e non dipenda da una sua particolare configurazione a livello locale.

l’integration build può essere manuale o effettuata automaticamente tramite un continuous integration server (come hudson o cruisecontrol). sebbene quest’ultimo componente non sia obbligatorio, è comunque raccomandato usarne uno: sarà lui per noi a rilevare i cambiamenti sul repository ed eseguire le build automaticamente, fornendo inoltre una comoda dashboard con report sui test, code coverage, strumenti di analisi aggiuntivi e documentazione auto-generata.

non scaricare codice difettoso dal repository, riparare immediatamente le build rotte

nella malaugurata ipotesi in cui la build di integrazione fallisca, nonostante siano state correttamente passate le build private, sorge il problema della “broken build”: è entrato un bug nel codice del repository e tutti coloro che andranno a scaricarlo otterrebbero del software non funzionante.  è compito dell’ultimo sviluppatore che ha eseguito la commit risolvere il problema, ma visto che questo malfunzionamento coinvolge tutto il team è meglio non scaricare affatto il codice difettoso: invece che perdere tempo nello sviluppo di eventuali workaround è preferibile aiutare gli altri a far tornare la build nello status di “green”.

build veloci e rapid feedback

è importante che il processo di build sia veloce e rapido: non è accettabile attendere più 10 minuti per il risultato dei nostri test (regola del “10 minute build”), altrimenti si perderà troppo tempo per via delle molteplici integrazioni o peggio ancora lo sviluppatore tenderà ad accumulare molto codice prima di lanciare i test. per evitare questo anti pattern è consigliabile quindi eseguire delle staged-build ossia lanciare le build private accompagnate solamente da test leggeri (unitari) e le build di integrazione divise in due: test unitari prima (per individuare subito problemi grossolani) per le build lanciate ad ogni commit e test più approfonditi (unitari e funzionali, analisi del codice, delle dipendenze, del code-style ecc) per build lanciate in un successivo momento, magari schedulate in notturna (nightly build) o in seguito al successo delle precedenti commit-build.

in questo modo si ottiene un feedback immediato che deve essere coadiuvato da meccanismi che lo rendano facilmente individuabile e  interpretabile: una lampada sempre verde che diventa rossa in caso di build rotta è uno degli esempi più tipici. è importante che il feedback sia incentrato sulle informazioni utili ed essenziali, tutto il superfluo tenderà a distrarre lo sviluppatore, che nella confusione rischia di ignorare messaggi importanti.

i pro ed i contro

il rispetto di una pratica richiede un iniziale costo dovuto dalla intrinseca curva di apprendimento che presenta. test automatici e buone pratiche di programmazione hanno un costo in termini di tempo, come pure l’acquisto e l’uso di macchine dedicate per simulare l’ambiente di produzione; tutto questo, nel brevissimo termine, potrebbe essere visto come un overhead. tali costi verranno però ampiamente ripagati durante il ciclo di sviluppo del nostro software. ne beneficerà la qualità del codice sviluppato: grazie al testing continuo infatti si ha sempre la certezza che niente è andato storto. ansia e stress caleranno: se tutto quel che viene scritto è sempre attestato come funzionante da opportuni test, automaticamente cala anche la paura di andare incontro a imprevisti ed inconvenienti. la comunicazione all’interno del team aumenterà: grazie al feedback rapido e condiviso, tutti sanno a che punto è lo sviluppo del software, quali sono i problemi emersi e le funzionalità ancora da implementare. anche il rapporto con il cliente trarrà dei benefici: la maggior tranquillità e sicurezza sul progetto verranno percepite come sintomo di puntualità e professionalità. ultima ma non  meno importante è infine la possibilità di poter effettuare continui rilasci di nuove versioni del nostro software: nel repository infatti è presente in ogni momento software perfettamente funzionante e quindi “deployable”.

questione di pratica

in questa introduzione abbiamo parlato di buone pratiche (tante) e citato alcuni strumenti (pochi) per mettere in piedi un ambiente di continuous integration. è infatti sulle pratiche di sviluppo il vero investimento che un team di lavoro dovrebbe sostenere, perchè dietro a tutte le tecnologie, anche le più valide e promettenti, ci sono sempre le persone. la continuous integration ne prende atto, facendosi carico di tutti quei compiti che rendono dura la vita dello sviluppatore, che potrà dedicarsi finalmente a compiti di più alto livello e alla vera business logic di progetto.

una miglior comunicazione tra stakeholders ed un ambiente mitigato da ansia e stress sono i primi ingredienti per vivere ogni progetto come una nuova sfida, vissuta con proattività e voglia di fare: non dimentichiamo mai che il software, benché eseguito da macchine, è sempre scritto da persone

per chi volesse approfondire consiglio la lettura dell’articolo originale dal sito di martin fowler ma soprattutto dell’ottimo libro “Continuous Integration: Improving Software Quality and Reducing Risk” (http://www.integratebutton.com/).

giorgio

in questo articolo andremo ad illustrare i passi necessari per la configurazione di tripwire, uno dei più diffusi host based IDS. disponibile sia in versione open source che in versione commerciale, è un software che una volta installato e configurato ci informerà di tutte le modifiche che avvengono nel file system, rispetto ad uno stato iniziale considerato “sicuro” che verrà salvato in un database.

su un sistema operativo come ubuntu, possiamo installare il software con un semplice apt-get install tripwire

al termine dell’installazione verrà avviata automaticamente la configurazione iniziale del programma, durante la quale ci verrà chiesto di inserire la “site key” e la “local key”, con cui tripwire provvederà a creare in /etc/tripwire i file di configurazione con le policy di default, in particolare i file tw.cfg e tw.pol. è consigliato rendere questi file leggibili solo dall’utente root con il comando chmod 0600 /etc/tripwire/tw.cfg /etc/tripwire/tw.pol

da notare che questi 2 file sono binari, creati partendo dai due file plain text twcfg.txt e twpol.txt, saranno quindi questi due file che dobbiamo modificare per apportare modifiche alla configurazione. per un primo utilizzo possiamo lasciare le versioni di default; consiglio solo, nel caso in cui si voglia che i report vengano inviati per email, di aggiungere al file twcfg.txt la riga

GLOBALEMAIL   = email@miodominio.it

una volta modificato il file twcfg.txt occorre ricreare il corrispettivo file binario, per farlo possiamo utilizzare il comando twadmin –create-cfgfile -S site.key /etc/tripwire/twcfg.txt

nel caso in cui venga invece modificato il file twpol.txt per ricreare il binario tw.pol dobbiamo utilizzare il comando twadmin –create-polfile -S site.key /etc/tripwire/twpol.txt

a questo punto, possiamo creare tramite il comando tripwire –init il database iniziale che tripwire utilizzerà per confrontare lo stato del sistema ad ogni check, il file verrà creato nella cartella /var/lib/tripwire/

ora non ci resta che testare il funzionamento di tripwire utilizzando il comando tripwire –check –email-report che ci invierà per email il report con tutti i file di sistema modificati, aggiunti o cancellati dalla creazione del database iniziale. il consiglio è naturalmente quello di inserire il comando in crontab per far generare automaticamente i report quando volete.

nel caso in cui si voglia modificare il file /etc/tripwire/twpol.txt, ecco un semplice esempio di regola che possiamo aggiungere:

(
rulename = “Sito web www.miosito.it”,
severity = N, (dove N è un numero compreso tra 0 e 100, più alto è il numero più alta è la ‘criticità’ di questa sezione)
emailto = webmaster@miosito.it
)
{
/var/www/www.miosito.it                  -> $(SEC_CRIT) ;
}

nel dettaglio, questa regola provvederà ad ogni check di inviare una mail a webmaster@miosito.it con tutti i file modificati di uno specifico sito.

un ultimo consiglio: vista la comprensibile sensibilità dei file di configurazione, è buona norma non tenere i file di configurazione plain text, ma di cancellarli ogni volta che si è conclusa la configurazione. per future modifiche possiamo sempre rigenerarli utilizzando i comandi:

twadmin –print-polfile
twadmin –print-cfgfile

daniele

non solo una questione di editor, o di sistemi integrati per lo sviluppo ma un discorso di piattaforma, di sistema operativo e di applicazioni. già nel titolo del post spicca una parola mac,  inutile discutere le scelte ma di certo va ancora di moda associare questo sistema operativo solo ai lavori di “grafica”… parola che oltretutto da sola significa tutto e niente.

in questo articolo vorrei spiegare come ho creato il mio ambiente di lavoro ideale su questa piattaforma utilizzandone le potenzialità che apprezzo senza rinunciare alla personalizzazione e senza compromessi rispetto alle esigenze dell’infrastruttura aziendale. da front-end web developer necessito innanzi tutto di una suite di lavoro dalle caratteristiche web-creative che sia potente, efficace e soprattutto compatibile col gli standard utilizzati dai grafici e creativi. inutile dire che tra le migliori troviamo la adobe con la sua creative suite web premium: massima compatibilità con la piattaforma mac e possibilità di operare con la totalità dei file che provengono dagli studi grafico-creativi.

ho poi bisogno di un editor, visto che nell’ultimo periodo abbiamo cambiato modalità di lavoro optando per un sistema con controllo della versione, la scelta è stata già scremata dalle applicazioni che non rispettano queste caratteristiche. inizialmente, reduce dalla vecchia modalità di lavoro, mi sarei accontentato di un editor e da un sistema di versioning separato. ho provato coda e taco come editor testando parallelamente subversion, version e syncro SVN per il controllo della versione. risultati abbastanza soddisfacenti ma il software sopra citato non è tutto freeware.

successivamente, in base anche alle esperienze dei colleghi, ho preferito un software unico più potente (anche se più pesante), in grado di elaborare tutti i formati, con un alto livello di personalizzazione (anche per la parte di colorazione del codice), con un alto livello di utenza (e quindi una community affidabile), con una estendibilità in grado di soddisfare ogni esigenza e freeware. la scelta si è spostata su eclipse, software disponibile sia per windows, per linux e per mac che tramite il plugin subversive installa anche il sistema per il controllo della versione.

ora manca solo un web server da installare sulla macchina per lavorare in locale che in base alle caratteristiche aziendali dovrà essere LAMP (linux, apache, mysql, php), mi sono subito orientato alla scelta verso l’ambiente MAMP molto “apple formed”, gratuito ed immediato tanto che è segnalato anche tra le migliori applicazioni per mac. MAMP ha una start-up page immediata che ingloba le preferenze scelte, link alla pagina info.php e link alla gestione dei database con il pannello di phpmysql e un widget appositamente creato per la dashboard di machintosh che permette di avviare e stoppare il server in qualsiasi momento in maniera molto rapida.

potremmo essere pronti per lavorare ma vorrei soffermarmi su un aspetto più tecnico e macchinoso. lavorare in locale esige la modifica del file di hosts. questa modifica da mac non è immediata. di seguito spiego minuziosamente i passaggi da fare in modo da permettere anche ai non tecnici di poterlo effettuare autonomamente.

il file di hosts, come su linux, si trova dentro la cartella /etc. per andarci dal nostro finder scegliere il menu “vai” quindi “vai alla cartella” e scrivere /etc ci si apre la finestra dove possiamo trovare il file hosts che se apriamo con un editor o con l’applicazione di default text edit ci mostra il contenuto del database di hosts della macchina. in teoria dovremmo aggiungere una riga inserendo la regola che fa rispondere al nostro indirizzo locale la cartella di lavoro ma il problema è che il nostro utente, seppur amministratore della macchina, non ha i privilegi per modificare questi settaggi sensibili.

occorre infatti diventare utente root del nostro mac. come fare? in questo post vengono spiegati molto bene i passaggi da fare anche nel più recente sistema operativo snow leopard che ha rivisto l’organizzazione di certi menu. seguita la procedura avremo abilitato l’utente root (associando ad esso una password) ed ora dobbiamo abilitarlo utilizzando la shell. nelle “applicazioni” c’è la carella “utility” quindi l’applicazione “terminale”. digitiamo la parola “su” (per diventare super utente, appunto root) e alla pressione di invio ci verrà chiesta la password (quella che abbiamo scelta quando abbiamo abilitato l’utente root). a questo punto ci verrà restituito il prompt da utente root per quella sessione di terminale. digitiamo il comando “vim/etc/hosts” (che equivale a dire modifico il file hosts sito dentro la cartella /etc) e alla pressione di invio ci verrà aperto dentro il terminale il file hosts. premere la lettera “I” per effettuare l’editing e una volta aggiunta la riga necessaria premere il tasto ESC seguito dai due punti. ora digitare “wq” (write and quit) per uscire dall’editing.

alessandro

photo credits: apple command

varie sessioni di ricerca e test ci hanno portato a considerare ispconfig uno dei migliori software open source in questione disponibili nel mercato. come riportato dal sito web ufficiale, ispconfig è un “pannello di controllo hosting open source, disponibile sotto licenza BSD. è attualmente disponibile in due versioni: ispconfig 2, ancora supportata e considerata più stabile e ispconfig 3, più recente e senza dubbio migliore nell’interfaccia, ma ancora non ha tutte le utilità di ispconfig 2 (vedi ad esempio l’assenza di add-ons ufficiali, che di certo non tarderanno ad essere sviluppati).

ispconfig è interamente scritto in php, il che lo rende facilmente espandibile e personalizzabile da aziende come e-xtrategy che prediligono lo sviluppo di applicazioni scritte in questo linguaggio di programmazione. come ogni buon software open surce che si rispetti,  ha un’ottima documentazione, disponibile in rete riguardante l’installazione e la configurazione, a partire dalla documentazione ufficiale, fino ad arrivare alle utili guide e i forum di supporto presenti su howtoforge, i cui gestori sono gli ideatori di ispconfig.

la lista delle features è veramente vasta, infatti grazie ad ispconfig possiamo eseguire tutte le operazioni che ci permetteranno di amministrare il nostro server hosting (gestione di spazio web, account ftp, account email, dns ecc.), il tutto tramite un’interfaccia web altamente user friendly. per quanto riguarda la gestione del server web, una delle funzionalità che riteniamo molto utile è la possibilità di scegliere la modalità con cui verrà eseguito il php per ogni sito che andremo a creare, potendo scegliere tra suphp, fast-cgi, mod-php e cgi in base al carico e agli accessi che presumiamo il sito potrà avere.

come detto, ispconfig è scritto in php e, in caso si vogliano apportare delle modifiche al codice, la sua semplice disposizione dei file ci permette con un po’ di pratica di trovare in poco tempo le parti di codice che cerchiamo. tutti i file sono presenti nella cartella
/usr/local/ispconfig/
e nella cartella
/usr/local/ispconfig/server
troviamo tutti i php che vengono eseguiti ogni qualvolta eseguiamo un’operazione dall’interfaccia web, ad esempio
/usr/local/ispconfig/server/plugins-availabl/email_plugin.inc.php
è  il file verrà eseguito ogni volta che andiamo a inserire/modificare un nuovo account email.

nella cartella
/usr/local/ispconfig/server/conf
sono invece contenuti i template dei file di configurazione per ogni applicazione, ad esempio il file
/usr/local/ispconfig/server/conf/vhost.conf.master
è il file template che verrà utilizzato da ispconfig per generare il virtualhost apache ogni volta che andremo a creare un nuovo sito web.

daniele

guest post di alfredo morresi – software engineer

pubblichiamo con piacere un articolo nato da una riflessione di alfredo che tratta di un argomento innovativo su cui ci stiamo confrontando in questo periodo.

sovrapporre uno o piu’ strati informativi alla realta’ davanti ai nostri occhi, mostrare dati provenienti dalla rete agganciati a cio’ che stiamo vedendo: a piu’ di 20 anni di distanza, la visione dei grandi autori del cyberpunk, come gibson in “luce virtuale”, incontra una tecnologia in grado di farla diventare concreta e alla portata di tutti. nascono cosi’ interessanti scenari di realta’ aumentata: un nuovo mondo da scoprire, sempre piu’ mobile, sempre piu’ con noi anche fuori da casa e dal lavoro.

i cyborg della serie terminator poteva vedere informazioni aggiuntive in sovraimpressione a quanto i loro occhi inquadravano: nome della persona, dati sui veicoli, strada da percorrere. seppur vecchio di 25 anni, questo e’ un primo esempio di cosa si puo’ fare con la realta’ aumentata. da una fiction holliwoodiana del 1984, passiamo ai giorni nostri, dove i telefonini piu’ avanzati hanno portato questa stessa possibilita’ alle masse. basta mettere a fuoco un monumento per conoscere il suo nome e una dettagliata descrizione, presa dalle pagine di wikipedia; trovarsi davanti ad un negozio ed accedere alle recensioni scritte dagli utenti, puntare una strada e sapere che, in fondo a destra, c’e’ una pizzeria, potendo anche navigare sul suo sito internet.

ma come’ possibile questa magia? parte del merito e’ dei device mobili di ultima generazione, che da telefonini si sono evoluti fino a diventati smartphone e, oltre ad offrirci un collegamento in mobilita’ alla rete internet, sono in grado di capire esattamente dove si trovano nello spazio. il gps fornisce le coordinate, gli accelerometri l’inclinazione, la bussola la direzione. combinando questi tre fattori, e’ possibile determinare quali oggetti, con una posizione nota, ricadono nel raggio visuale della fotocamera del device. proprio questo e’ il compito di programmi come layar, wikitude, theodolite ed altri, che rielaborano il flusso di immagini riprese e lo combinano con le informazioni georeferenziate presenti nei loro database: indicazioni stradali, monumenti, dati sugli esercizi commerciali, modelli tridimensionali.

eh si, perche’ da poco queste applicazioni sanno anche ricostruire complesse forme geometriche e collocarle davanti ai nostri occhi. e’ possibile cosi’ rivedere le torri gemelle puntando un iphone su groud zero, oppure scoprire, prima della sua costruzione, come sara’ il cantiere del nuovo market hall, a rotterdam : esplorarlo, girandoci attorno ed entrandoci dentro. ancora, scovare piccoli invizimals a passeggio per la casa e scatenare poi duelli tra di loro, vedere come sara’ l’aspetto di una costruzione lego mettendo la scatola davanti ad un apposito specchio. interessante anche il concept proposto da ikea, grazie al quale si stampa un apposito codice a barre bidimensionale di un prodotto preso dal loro catalogo, ad esempio un letto, si posiziona il foglio dove questo prodotto dovrebbe andare, si inquadra con la webcam la stanza e il computer ci svela, in anteprima, come apparira’ con il letto montato e posizionato. non ci piace? nessun problema, stampiamo un nuovo codice, lo mettiamo al posto di quello vecchio e controlliamo il risultato. quando siamo finalmente soddisfatti, il computer sa gia’ con quali prodotti stiamo arredando la camera e li ordinera’ per noi.

scordiamoci anche i navigatori cosi’ come li conosciamo oggi: non piu’ una mappa con il percorso da effettuare, ma precise indicazioni sovrapposte direttamente sulla strada davanti ai nostri occhi. oggi, grazie a wikidrive su uno smartphone, domani proiettati sul parabrezza della nostra auto. dopotutto, gli aerei militari utlizzavano l’hud fin dagli anni ’80, si vedono gia’ le prime macchine con collegamento ad internet incluso negli optional, e’ solo una questione di tempo prima che qualche casa costruttrice trovi un accordo con un fornitore di servizi e includa nella gamma top delle sue vetture un “visio-navigatore”.

un altro comparto dove la realta’ aumentata ha grandi potenzialità di sviluppo, e’ quello del mobile social gaming: pensiamo ad una caccia al tesoro collaborativa, dove gli indizi virtuali sono disseminati all’interno di un percorso urbano, dove precisi eventi innescati da un team possono cambiare il corso dell’avventura a cui anche altri team partecipano: una spia si nasconde all’angolo del parco: il primo team che la trova, inquadrandola con un telefonino, ricevera’ preziose informazioni. a questo punto la spia va via, oppure si muove e non sara’ piu’ rintracciabile nello stesso luogo, ma in un posto diverso, che i successivi team dovranno scoprire. magari potremmo anche incontrare i beatles per strada.

ovviamente anche il turismo potrebbe beneficiare di queste innovazioni. se gia’ prima si parlava della possibilita’ di sapere nome e informazioni aggiuntive su un monumento, un’opera d’arte, un luogo, pensiamo a quanto potrebbe diventare divertente, e formativa, la visita ad un sito storico se arricchita dalla possibilita’ di vedere scene di vita provenienti dall’antichita’: i fori romani ricostruiti in tutto il loro sfarzo, gli affreschi di una facciata nella loro brillantezza originaria. basta inquadrare e muoversi, per conoscere cosa c’era prima. la nuova frontiera delle guide interattive.

dobbiamo comunque precisare che questa “prima generazione” di software per la realta’ aumentata non riconosce gli oggetti che vengono messi a fuoco dalla fotocamera del dispositivo, ma, come dicevamo prima, presumono che in quello scorcio di realta’ ci sia qualcosa solamente basandosi sulla sua posizione. un limite che, un po’ alla volta, verra’ superato, come gia’ ci sta mostrando google goggles, annunciato pochi giorni fa.

in ultimo, una buona notizia per gli sviluppatori. non occorre avere decine di migliaia di euro alle spalle per realizzare uno di questi software: layar e wikitude, ognuno con le sue peculiarita’, mettono a disposizione client o api per android e per iphone che fanno quando abbiamo descritto fin qui, con la possibilita’ di integrare propri dati. anche gratuitamente.

insomma, l’hype intorno a questo settore e’ davvero alto, e non tarderanno ad arrivare applicazioni che saranno in grado di lasciarci con il fiato sospeso, ancora di piu’ rispetto a quanto visto fino ad ora. sono convinto che ci troviamo di fronte ad uno stagno appena scoperto: qualche buona idea, iniziativa e un minimo di voglia di rischiare saranno l’esca giusta per tirare su i grossi pescioni che lo popolano. cosa state aspettando?

alfredo morresi