Intervista a Paolo Possanzini, Co-fondatore, CTO e socio di TeamDev, nonchè co-fondatore della community DotNetUmbria.
Appassionato da sempre di programmazione, dal 1998 l’ha fatta diventare una professione.
Paolo ha realizzato di recente una struttura software molto utile e interessante che permette di integrare facilmente i sistemi cartografici negli applicativi web e mobile, per cui è stato chiamato in più occasioni a parlarne approfonditamente davanti a un pubblico sempre più vasto.
Abbiamo deciso perciò di intervistarlo per saperne di più di questo prodotto.
- Cosa ti ha spinto a realizzare questo framework?
Intanto parliamo di cosa è un framework; un framework è un insieme organizzato di funzionalità per svolgere un compito specifico. Normalmente non si scrive un framework per far fronte alle esigenze di un singolo progetto, ma se si vuole riutilizzare il lavoro fatto per più progetti in modo organico, allora è conveniente organizzare parte del lavoro a formare un framework indipendente da riutilizzare. La spinta è nata appunto dall’esigenza di sviluppare molti lavori che includevano servizi cartografici, e quindi dal voler riutilizzare il lavoro fatto, e anche dall’uniformare il modo in cui in TeamDev stavamo integrando i componenti Javascript di Esri nei nostri lavori in AngularJS.
- Quali sono i vantaggi in termini di risparmio di scrittura di righe di codice?
I vantaggi sono notevoli. Nella modalità tradizionale è necessario implementare in javascript tutta la parte di creazione e gestione della mappa e di tutte le parti grafiche. Di solito ci si trova a scrivere in Javascript tutta una serie di cose che in realtà fanno parte non della logica di manipolazione dei dati ma di logica di visualizzazione.
Nella programmazione moderna si tende a dividere i problemi e risolverli in modo specifico. Noi abbiamo diviso tutta la parte di grafica dalla parte di logica, ed abbiamo implementato il tutto in modo da dover scrivere in javascript solo la parte che riguarda la logica dei dati. La parte di grafica è in HTML (che nel web è il linguaggio più naturale per descrivere la grafica). Abbiamo scritto tutto inserendo delle “direttive” che ci permettono di scrivere Tag customizzati estendendo di fatto l’HTML che andiamo a scrivere.
- AngularJS cosa mi offre in più rispetto al resto? Quali sono le caratteristiche del framework AngularJS che lo rendono migliore rispetto ad altri framework?
AngularJS è molto completo e permette una ottima divisione del progetto in modo da separare le parti (logica di business, grafica, validazioni, etc) in modo organico. Ci sono altri framework che eseguono questo compito altrettanto bene, ma nei nostri progetti scegliamo Angularjs sia per la sua diffusione, sia per la sua stabilità e velocità di sviluppo. E’ la sua completezza che lo rende appetibile, inoltre porta lato browser un modello di sviluppo organico tipico di applicazioni più complesse e in passato relegate solo ad una gestione lato server
- Quali sono gli aspetti di AngularJS che lo rendono così adatto all’integrazione con il GIS?
AngularJs permette una fortissima separazione della logica necessaria per la gestione della parte grafica dalla logica necessaria per gestire i dati di un’applicazione complessa e per interagire con servizi esterni. In un’applicazione GIS ci sono tantissime componenti grafiche che non sono descritte direttamente dal linguaggio HTML e che quindi necessitano di una gestione “speciale”. Angular permette di affrontare questa problematica in modo elegante rendendo possibile creare elementi del linguaggio HTML ad Hoc, senza dover mischiare le parti di gesitone dei dati con la parte di descrizione della parte grafica dell’applicazione.
- Da un punto di vista prestazionale il fatto di essere una framework e non una semplice libreria come si comporta AngularJS?
Sviluppando il nostro progetto come framework siamo obbligati a guardare un po’ più in grande ed in prospettiva rispetto allo sviluppo di una libreria che può avere una vita più breve ed un ambito più ristretto.
Un framework deve essere organizzato in modo più organico e quindi devono essere risolti a livello di “design” le problematiche di interazioni tra le varie parti del framework stesso e con il mondo esterno. Solitamente questo si traduce in una maggiore libertà di espressione dello sviluppatore che lo utilizza, perché per descrivere un comportamento complesso è necessario una minore quantità di codice che diventa più leggibile ed organico.
La semplificazione del codice si traduce poi in una maggiore velocità di esecuzione, appunto perché la descrizione del processo è più semplice e breve.
E’ un circolo virtuoso che si innesca in questo tipo di progetti, che permette una maggiore manutenzione del codice, ed una comprensione migliore del codice scritto da altri e quindi una migliore qualità dei prodotti realizzati.
- Le api fornite da esri si basano fortemente su dojo, un framework distinto da angularjs. come avviene la convivenza tra i due?
La parte più complicata è stata capire il modo migliore per mettere a disposizione di uno sviluppatore angular, alcune logiche di dojo che sono diverse. Una volta scoperta la metodologia adatta, tutto è diventato molto più semplice. In realtà il nostro framework esegue il lavoro di “traduzione” tra i due mondi in modo organico, uniformando le funzioni che esri mette a disposizione attraverso Dojo ad uno sviluppatore angular nel modo in cui lo sviluppatore angular se le aspetterebbe. Una volta fatto questo passaggio che poi in realtà è solo una differenza di alcuni formalismi, lo sviluppatore angular può utilizzare tutte le funzioni di dojo senza però rendersi conto che sta utilizzando un framework differente.
- Quale sviluppo futuro è previsto per il framework?
Stiamo implementando le parti dell’ARCGIS Javascript Api che ci sembrano più utilizzate nello sviluppo quotidiano. Alcune parti sono già state portate completamente. Stiamo inoltre inserendo degli automatismi a cui gli sviluppatori angular sono abituati ma che in dojo sono assenti.
Da questo punto di vista angular è molto flessibile.
Stiamo dando anche una particolare attenzione ad una parte un po’ più di automazione della programmazione : il supporto intellisense (suggerimento della scrittura del codice) all’interno degli strumenti di sviluppo. Questo ci evita di commettere errori in quanto l’ambiente di sviluppo conosce il framework e ci indica dove stiamo sbagliando.
E’ molto importante perché programmando in javascript si ha una grande libertà, ma anche una grande possibilità di commettere errori. Evidenziare le cose che possono non funzionare mentre le stiamo scrivendo semplifica molto il processo.
- Quale impatto ha l’uso del framework nel workflow di sviluppo?
La separazione della parte di grafica dalla parte di logica ha degli effetti incredibili sia dal punto di vista della libertà di espressione sia dal punto di vista della velocità.
E’ tutto molto più organizzato e semplice.
- Qual è stato il nodo più difficile da sciogliere per far coesistere angularjs e dojo?
La parte più difficile è stata trovare un buon modo per dare la giusta libertà di espressione in punti in cui DOJO prevede formalismi diversi. Abbiamo dovuto studiare bene alcuni internals di angular e del framework ESRI in particolare per raggiungere il risultato voluto. La parte su cui stiamo puntanto attualmente l’attenzione è sempre legata all’espressività di programmazione ma non sulla parte HTML ma sulla parte di logica di business.
- Nel framework angular c’è tutto il necessario o comunque, in alcuni frangenti, si fa uso di jquery?
Angular include una versione ridotta di JQuery, viene utilizzato internamente per manipolare il DOM. solitamente non è necessario ricorrere a JQuery, lo sviluppatore angular ha così tanti strumenti che è spesso inutile fare ricorso a JQuery in modo esplicito.
L’unica motivazione valida è la necessità di utilizzare un plugin non sviluppato per angular.
- Si fa uso dello spazio di archiviazione del browser? Se si perché?
A volte si fa uso dello spazio del Browser.Si utilizza tipicamente per mantenere alcuni dati dell’utente. Noi lo abbiamo utilizzato per fare caching delle cartografie in modo da permettere la manipolazione delle mappe anche in assenza di connessione ad internet, questo è specialmente indicato per applicazioni mobile.
- Quanti e quali servizi di geocodifica sono stati integrati nel framework?
Il framework implementa i servizi di geoprocessing per la ricerca ed il calcolo dei percorsi stradali e direzionali, ed implementa direttamente i servizi necessari a manipolare le geometrie.
- Il framework offre agevolazioni per la conversione tra diversi sistemi di riferimento di coordinate?
Tutte le mappe sul Web utilizzano il sistema di riferimento Web Mercatore.Un’altro sistema di riferimento molto utilizzato è WGS 84, noi cerchiamo di capire in quale sistema di riferimento siamo e facciamo in alcuni casi le conversioni necessarie. Mettiamo comunque a disposizione la possibilità di indicare il sistema di riferimento e facciamo noi la conversione negli oggetti visuali. Abbiamo in cantiere alcuni tools che agevoleranno ulteriormente la conversione
- Il framework espone metodi di interfacciamento con i ruoli e gli utenti di AGOL?
Non direttamente. Riconosciamo se l’utente è già loggato e se loggato utilizziamo i sui dati per interrogare i servizi che richiedono una autenticazione, ma non mettiamo a disposizione strumenti particolari diversi da quelli già presenti nel framework ESRI
- Qualche esempio di lavori in cui lo hai già applicato?
- Il nuovo NIR per ARPA (dovrebbe essere online)
- La nuova versione di Acqua che bevo (non ancora pubblicato)
- Agricolus
- Oliwes
- Oliwes APP sia per Android che per IOS
- Circuiti del paesaggio
- Trip stories
- Puoi descrivere in due parole il framework per i “non addetti ai lavori”?
Il framework mette a disposizione di sviluppatori esperti e non un modo facile, espressivo e veloce per integrare cartografie all’interno delle applicazioni WEB e Mobile. Con poche righe di HTML è possibile creare delle belle applicazioni che fanno utilizzo delle mappe non solo per trovare dei luoghi ma per fare operazioni anche molto più complesse.