Hackathon Cellenza Septembre 2014 : Géolocalisation avec DocumentDB et les API Bing

Chez Cellenza, le Bootcamp c’est une tradition. Une journée par mois, tous les collaborateurs de la société se retrouvent au siège pour échanger et apprendre ensemble. C’est certainement une des meilleures méthodes pour assurer la cohésion du groupe et partager nos connaissances acquises en mission.

Pour le Bootcamp de Septembre, Anne et Marine ont voulu changer le format habituel et nous ont proposé un hackathon. Les thèmes étaient libres, les technologies aussi.

Cet article est le retour de toute l’équipe « Les gendarmes de Saint-Tropez » qui s’attaquaient au problème de la localisation des Cellenzans en utilisant DocumentDB (la toute nouvelle base NoSQL dans le Cloud de MS)… Alors oui, c’est comme de dire qu’on attaque le problème de la construction d’une maison en utilisant des géraniums, mais nous on aime les défis !

L’équipe

On en parle mais la voici (dans l’ordre alphabétique) :

• Alexandre Plassais, Consultant Sénior Data & BI
• David Joubert, MVP SQL Server BI & Analytics
• Florian Eiden, MVP SQL Server BI & Analytics
• Guillaume Rouchon, MVP Visual Studio ALM
• Nicholas Suter, MVP Visual C#
• Sébastien Boinot, Consultant Sénior ALM

Oui, ça envoie du lourd. Enfin du lourd dans des disciplines qui n’ont finalement pas grand-chose à voir avec de la géolocalisation, mais ça c’est un détail !

La démarche

La première heure, nous avons interviewé nos utilisateurs, défini un MVP, écrit le backlog, les cas d’acceptance et défini l’architecture.

En 3h, nous avons réalisé une première maquette d’écran, levé les inconnues techniques sur Bing et DocumentDB, provisionné l’usine de développement sur VSO et mis en place le déploiement continu vers Azure.

En 7h, l’application fonctionne, elle est démontrable.

Le livrable : une application de géolocalisation des consultants

Un site web ASP.NET MVC 5, déployé sur Azure et appuyé sur une base DocumentDB, permettant de :

• Afficher une carte et la centrer sur Paris
• Localiser sur la carte par des « Push-Pins » (punaises) les emplacements des Cellenzans déjà renseignés dans la DocumentDB – en notant qu’un clic sur un Push-Pin affiche une « infobox » avec les détails associés (nom, prénom, adresse et date du dernier check in du Cellenzan)
• Enregistrer ou mettre à jour sa position à travers un petit formulaire

Les technos

Pour l’affichage de la carte, nous avons utilisé les API Bing Maps AJAX Control, Version 7.0 pour leur facilité d’utilisation et leur rapidité de mise en place. La difficulté ici était de générer dynamiquement le code JavaScript pour afficher les Push-Pins (punaises) sur la carte.

L’affichage de la carte en lui-même passe par la déclaration de l’url de l’API Bing maps et la création d’une méthode « GetMap() » qui l’initialisera (oui on vous met du code en image, c’est plus joli, mais n’hésitez pas à envoyer un petit mail pour les sources – évidemment, on clique dessus pour voir en grand):

Puis, pour afficher les Push-Pins, nous avons utilisé le moteur Razor pour parcourir la listes des « check-ins » (à partir du Model de la vue) et ainsi générer dynamiquement le code javascript de création des Push-Pins :

Côté DocumentDB, la techno en elle-même n’est pas méchante (ce serait un comble pour du NoSQL), et une fois mise en place, elle s’emploie facilement. Attention cependant :

• Il existe une colonne implicite “id” qui est automatiquement ajoutée à tout document. Il est possible de spécifier la valeur manuellement mais attention à la casse, il faut que ce soit en minuscule !
• Les APIs utilisent des liens pour spécifier la db, la collection et le document. Il faut donc, au niveau du document, jongler entre nos entités et l’objet Document qui contient le lien unique pour réaliser certaines opérations (le replace par exemple)
• Pas d’interface graphique intégrée au portail Azure pour le moment. Cela manque pour administrer les collections et jeter un coup d’œil rapide à ce qu’il se passe en debugging
• C’est une techno qui a pour objectif de faire disparaître la couche de stockage ou, au moins, de minimiser son importance dans le design de l’application. Alors évidemment on gagne sur le court terme, l’implémentation est facile et rapide, mais à long terme cela peut se payer, principalement sur le manque de maîtrise sur l’évolution des schémas de données. A ne pas oublier…

Enfin, côté ALM, nous avons mis en place une démarche Agile avec VSO et Azure :

• Création d’une équipe dans un Team Project existant pour avoir un backlog produit et un taskboard
• Création d’un site web Azure
• Mise en place de continuous deployment avec VSO et le hosted build

Les points d’attention

• 3 consultants BI pour un projet applicatif c’est 2,5 de trop 🙂
• DocumentDB : en phase de preview seulement depuis quelques semaines, le déploiement est long (très long pour la génération des clefs) et la documentation est encore incomplète (mais ça s’améliore)
• API REST Bing : nous avons quand même bien galéré avec un framework pas forcément optimisé qui nous a, par exemple, obligé à recréer à la main des objets identiques pour pouvoir récupérer les résultats. D’une manière générale, la documentation et les exemples sont bien trop dispersés

Conclusion

On a fini deuxième, on aurait dû gagner… 🙂

Plus sérieusement, le retour est partagé par tous dans l’équipe : c’est une expérience extrêmement enrichissante. En employant une démarche claire, nous avons obtenu un résultat très positif dans un délai restreint et surtout une bonne dose de fun ! Définitivement à refaire.