Service de covoiturage nouvelle-génération

Transcription

1 Service de covoiturage nouvelle-génération G. Bédard Sicé, E. Cantin, F. Courville, J.-M. Gingras, O. Lamarche, F. Néron et T. Tran Université de Sherbrooke Faculté de génie Département de génie informatique et génie électrique Résumé Cet article présente le projet LzGo, une plateforme de covoiturage nouvelle-génération. Cette plateforme permet de faciliter l organisation du covoiturage interurbain entre des conducteurs et des passagers. La solution développée favorise le covoiturage en étant plus accessible par ses faibles coûts d utilisation, plus simple en mettant à profit les nouvelles technologies et plus social en interagissant avec les médias sociaux. Tout d abord, une définition plus détaillée du système sera présentée. Puis, les choix technologiques seront abordés, tels que l architecture du système et les choix technologiques effectués. Finalement, il sera question des méthodes de validation et de tests utilisées au cours du développement du projet. Mots-clés Service de covoiturage, Ruby on Rails, ios, Android, SaaS, Application web I. Mise en contexte A. Introduction et motivation L utilisation du covoiturage est en pleine croissance au Québec. En effet, cette alternative à l utilisation de la voiture personnelle est une option de plus en plus choisie car elle est plus écologique et économique. Le projet LzGo est conçu pour devenir un joueur majeur dans cet écosystème. Pour se démarquer des services existants, LzGo suit la vague du Web 2.0 axée sur la simplicité et l interactivité. L intégration des médias sociaux avec une interface simple et intuitive rend l expérience de l utilisateur plus sociale et durable. Par exemple, la recherche de départ mets l emphase sur l interaction avec son réseau social personnel tels que ses amis Facebook. Ensuite, le service sera offert également en version mobile pour téléphones intelligents, dont l utilisation est en croissance fulgurante. Les utilisateurs pourront ainsi parcourir les offres, accéder à l information sur leurs départs et recevoir des notifications directement sur leur téléphone, facilitant la dynamique passager-conducteur. Le service sera offert sous forme de forfaits mensuels et sans frais d utilisation supplémentaires. Avec le modèle utilisé, les utilisateurs conducteurs et passagers effectueront des économies par rapport aux coûts demandés par les compétiteurs actuels. Le covoiturage étant alors non seulement écologique mais également plus économique, il sera donc plus accessible à tous. Ainsi, la mission du projet est d amener une alternative aux covoitureurs qui soit plus simple, plus sociale et plus accessible. B. État de l art Étant donné le modèle d affaires du projet LzGo, le domaine qui lui rapproche le plus est celui du logiciel en tant que service (de l anglais software as a service ou SaaS). Les technologies utilisées par les entreprises faisant affaire dans cet industrie ont longtemps tourné autour de la pile LAMP et ses variantes. En effet, la combinaison de Linux, Apache, MySQL et PHP a déjà fait ses preuves et est devenue le standard du domaine. Les logiciels offerts en tant que service sont en général très flexibles face à la demande. Leur architecture permet une évolutivité horizontale, assurant un niveau de service minimum relevé. Lorsque la charge d utilisation est trop grande, il est possible de dynamiquement déployer un nouveau serveur pour combler cette demande. De plus, le développement et déploiement de nouvelles fonctionnalités se fait plus rapidement que dans un modèle traditionnel de par le fait que l application est servie depuis un point central. L utilisateur n a donc plus besoin de faire de mises à jour pour profiter des plus récentes fonctionnalités. Ensuite, l utilisation d analytiques permettent aux développeurs de facilement cibler leurs changements pour s assurer de mieux satisfaire la demande de leurs clients. Les applications de type Saas, quoique souvent très différents les uns des autres, sont souvent bâtis sur les mêmes pilliers. Par exemple, on retrouve souvent un niveau d interface de programmation (API ou application programming interface en anglais) permettant à des tierces parties d avoir accès à certaines fonctionnalités sans utiliser l interface utilisateur. Ces interfaces offrent toutes sortes d avantages, comme le développement d applications mobiles ou même l automatisation de tâches via des scripts. Aussi, étant donné la présence en ligne de l application, on retrouve souvent une emphase sur la collaboration entre les utilisateurs. Servir une application en ligne offre de nombreux avantages aux utilisateurs aussi. Entre autres, le fait de ne rien avoir à déployer peut engendrer des économies de temps significatives. De plus, ces services sont généralement offerts à un prix moins cher que la compétition en application

2 de bureau. Finalement, étant donné que ces applications sont hébergés en ligne, le client n a pas à se soucier des investissements de matériel informatique. Ceci étant dit, les entreprises offrant des logiciels en tant que service ont aussi plusieurs défis à relever, notamment en terme de sécurité des données. L année 2011 a été particulièrement difficile pour la sécurité des données. Plusieurs grands sites, tel que Sony Playstation Network, on vu leurs failles de sécurité se faire exploiter, mettant en danger les données de plusieurs millions d utilisateurs. C. Défi technique Tout d abord, le système doit offrir les fonctionnalités primaires d un service de covoiturage, comme annoncer un départ en tant que conducteur et s inscrire à un départ en tant que passager. Ces opérations de base doivent au minimum être tout aussi faciles et agréables à utiliser que sur les services existants, sans quoi l utilisateur n aura pas intérêt à effectuer une migration vers LzGo. D autre part, les fonctionnalités qui permettront LzGo à se démarquer de la compétition devront être bien intégrées à l ensemble du système en place. Une des grandes nouveautés amenée est l interaction du système avec les médias sociaux. Cela permettra d étendre la visibilité du covoiturage non seulement à l intérieur du service luimême, mais également jusque dans le réseau social des utilisateurs. Par exemple, un conducteur pourra créer un départ sur LzGo et ensuite le partager à tous ses amis Facebook ou encore à ses followers Twitter. Ils pourront alors s inscrire facilement au même départ. Une autre fonctionnalité intéressante avec l interaction des médias sociaux est que le système mettra en évidence les départs effectués par son réseau social existant, encourageant donc les gens à voyager avec des connaissances et ainsi améliorer leur expérience de covoiturage. Ces fonctionnalités amènent de nouvelles opérations possibles à l utilisateur et il faudra s assurer qu elles soient faciles à effectuer et qu elles ne nuiront pas à l ergonomie de l interface. Aussi, le développement d applications mobiles représente également un défi à plusieurs niveaux. Tout d abord, il faut que le serveur d application puisse communiquer autant avec l application Web qu avec les différents appareils mobiles. Ceci engendre un défi au niveau de l architecture de l application ainsi qu au niveau de l infrastructure de déploiement. De plus, il est important de considérer que contrairement à l application Web, nous ne pouvons pas garantir que les utilisateurs des plateformes mobiles mettront à jour leurs applications. Il est donc important de pouvoir faire évoluer l application Web sans briser le fonctionnement des application mobiles antérieurs. Pour ce faire, il faut établir, dès le départ, une stratégie de versionnement sur laquelle nous pourrons nous fier. Également, la conception des interfaces mobiles exigera un tout autre mode de pensée qu avec celles du Web. Les lignes directrices à suivre quant à l ergonomie des interfaces mobiles définies par Apple [1] devront être suivies. De plus, il y a des délais avant la mise en ligne d une application sur le magasin itunes. Il faut donc tenir compte de ces normes lors du développement sur cette plateforme. Finalement, l important sera de s assurer que l intégration de toutes ces fonctionnalités rendent l expérience de covoiturage plus facile et agréable que chez les compétiteurs. Dans ce même ordre d idées, il faudra limiter le nombre de bogues au minimum. Pour ce faire, une stratégie rigoureuse des principes du test-driven development sera privilégiée. A. Architecture globale II. Description du système 1) Vue d ensemble: L architecture globale du système se compose de trois principaux sous-systèmes : l application Web, l application pour ios et l application pour Android. Cette organisation est présentée à la figure 1. 2) Application Web: L application Web est une application Ruby on Rails [2], architecturée selon le patron MVC (Model View Controller). Le patron MVC est fortement encouragé par Rails, pour ne pas dire impossible à éviter. Cela dit, ce patron est une meilleure pratique du Web, car il permet de séparer la logique d affaires de la représentation visuelle des données. 3) Applications mobiles: Les applications mobiles communiquent avec le système à travers l application Web. Cependant, plutôt que d utiliser des vues graphiques, elles utilisent des vues de structures de données selon le format JSON et organisées selon la structure REST (REpresentational State Transfer). Cette structure permet d utiliser des librairies tierces pour accéder et recréer les données de l API plutôt que d avoir à reconcevoir ce système. 4) Infrastructure de déploiement: Du fait de son organisation, l application Web est centrale à tout le système. L infrastructure sur laquelle elle fonctionnera doit donc être capable de répondre adéquatement à la demande. L architecture envisagée est donc une architecture distribuée, dont les secteurs les plus sollicités pourront se mettre à l échelle rapidement et facilement. Sur le schéma présenté à la figure 2, on peut apercevoir cinq machines différentes, mais ce nombre est sujet à de grandes variations. Les serveurs Web seront plaçés derrière un load balancer, qui leur distribuera les requêtes entrantes afin de répartir la charge entre eux. La trajectoire que prendra la requête d un client à travers l infrastructure est la suivante : Passer dans la couche de répartition de charge (load balancing en anglais) pour être assignée à un serveur Web Si c est une requête pour un objet statique, tel une image ou un fichier JavaScript, le serveur Web retourne l objet demandé. Sinon, il envoie la requête au serveur d application.

3 Application Web (Ruby on Rails) Navigateur Application ios Application Android Figure 1. Architecture des différentes applications Le serveur d application traite la requête et fait possiblement des requêtes sur la base de données. Si la requête génère des notifications, celles-ci sont envoyées au serveur de notifications, qui les renverra aux utilisateurs concernés selon leurs préférences. Chacun des serveurs Web comportera les logiciels suivants : Un serveur Web (nginx) Un serveur d application Ruby (thin) Un serveur de base de données esclave (MySQL) Ceux-ci, dont le schéma est présenté à la figure 3, seront présents en nombre variable et lancés dynamiquement afin de satisfaire à la demande. Figure 3. Esclave (MySQL) Serveur d'application (thin) (nginx) Schéma d un serveur Web dans l infrastructure envisagée En ce qui concerne le serveur de notifications, il enverra les notifications au navigateur Web via des WebSockets. Il s occupera aussi des notifications ios, Android, SMS et courriel. Ce sont spécialement ces dernières qui nécessitent un serveur à part. Par exemple, dans le cas des notifications ios qui sont envoyées à travers les serveurs d Apple, Apple demande qu une seule connexion TCP soit établie, et que tous les envois y passent. Les notifications Android et SMS ont le même genre de limitation. De plus, il semble logique de regrouper au même endroit toutes les manières de rejoindre un usager. B. Choix technologiques 1) Choix logiciels: Le premier choix crucial à prendre était celui concernant la plateforme de développement web. Les capacités d extensions et la communauté extrêmement présente autour de la technologie open-source Ruby on Rails a motivé l équipe à se diriger vers cette plateforme. La plateforme a définitivement fait ses preuves sur le Web avec les sites comme Twitter, Github et Groupon. Le manque d organisation du langage PHP et la difficulté d intégration du langage Java a conduit l équipe à s éloigner de ces deux choix. Une couche API de type REST retournant des réponses sous le format Javascript Object Notation (JSON) est utilisé pour communiquer entre les application mobiles et l application Ruby on Rails. Cette couche, bâtit avec le module Grape [3], est montée en tant que intergiciel (middleware en anglais). C est ce module qui s occupe, entre autre, du versionnement et de l internationalisation de l API. C est aussi cette couche qui sert d intermédiaire entre les applications mobiles et la base de données. Les applications mobiles ne se connectent donc jamais aux contrôleurs dans l application Web, ni à la base de données. Cela simplifie l architecture, éliminant une certaine complexité des applications mobiles et la gestion des

4 Serveur de base de données Maître Serveur push d'apple Serveur push Android Service d'envoi de SMS Mailer 1 n Esclave Serveur d'application Esclave Serveur d'application Traitement des notifications (ios, Android, SMS, ) Serveur de notifications (Web) Serveur de notifications Serveur de répartition Load balancer Application ios Application Android Navigateur Figure 2. Schéma de l infrastructure envisagée connexions à la base de données. Le type de base de données utilisé par l équipe est MySQL [4]. L expérience des membres avec ce type de base de données et la bonne compatibilité avec la plateforme Ruby on Rails ont rendu le choix facile. Les plateformes mobiles offraient aussi un choix considérable : l utilisation d un environnement de développement multi-plateforme (ios, Android) ou l utilisation des librairies natives des plateformes respectives. L équipe a penché sur ce dernier, permettant un développement plus spécifique et mieux intégré à la plateforme visée. Pour le système de contrôle de version, l ensemble des membres s est dirigé vers git [5]. En fait, ce système facilite énormément le développement de fonctionnalités en parallèle. Une étude approfondie des différentes possibilités ont motivé cette décision. 2) Choix matériels: Le développement mobile se fait sur deux types de plateformes différentes. La première est la plateforme ios, qui englobe la lignée de produits iphone et ipod Touch. Elle représente la plus grande part de marché des téléphones intelligents et il s agit donc d un incontournable. Le développement en tant que tel s effectue sur les modèles iphone 3GS, 4S et 5. La deuxième plateforme est Android, qui est en constante expansion en terme de part de marché dans les dernières années. Le développement se fait sur des unités d anciennes générations (Google Nexus One, LG Optimus One), permettant donc de mettre une emphase particulière sur la performance de l application.

5 Figure 4. Flux de travail du développeur III. Résultats, validation et test A. Méthodes de validation La validation et les tests sont une étape essentielle dans le développement informatique. L équipe a étudié la situation et en est venu à une entente sur les différents principes de fonctionnement du flux de travail, présenté à la figure 4. Les points suivants ont été retenus : Utilisation du système de dépôt de code source git Développement des fonctionnalités sur différentes branches Automatisation de la compilation et des tests des applications Couverture de code par les tests (>80%) Publication de la dernière version de la branche principale Lorsqu un développeur travaille sur une nouvelle fonctionnalité, il se doit d inclure les tests unitaires, fonctionnels et d intégration qui concernent cette fonctionnalité. Il doit aussi s assurer qu aucun autre test soit brisé avant d intégrer sa fonctionnalité dans la branche principale. Si les tests ne passent pas, l équipe est avertie par courriel. Ce courriel contient toutes les informations nécessaires à la correction du ou des tests fautifs. L automatisation de la vérification des tests et de la compilation de l application est faite avec Jenkins. Lorsqu un changement est poussé sur la branche principale du serveur, il compile l application et vérifie si les tests exécutent tous avec succès. Cet outil permet facilement de détecter un dysfonctionnement de l application et de le régler rapidement. Les personnes concernées peuvent corriger ce problème et s assurer de la bonne santé de LzGo sur l application Jenkins du serveur de l équipe. La dernière version de la branche principale est publiée sur un sous-domaine du site Web. À l aide de l authentifiant LDAP, l équipe peut permettre un accès restreint à l application. Cela permet à l équipe de tester l application dans un environnement d utilisation réel et d avoir la dernière version de l application sur la branche principale à portée de la main. Pour valider ses interfaces graphiques, l équipe compte utiliser l aide de différents outils statistiques analytiques. Avec celles-ci, l équipe peut prendre compte des différentes actions de l utilisateur et ainsi ajuster son interface. Ces outils sont notamment fournis par Google et permettent d augmenter considérablement la qualité de l application si les statistiques sont bien analysées. L application passera un stade alpha et beta. La version alpha sera fermée et sera réservée aux amis et à la famille de l équipe (Friends & Family) de façon à obtenir de la rétroaction à travers un contact direct avec les usagers. La phase beta sera aussi fermée, mais à base d invitations. L équipe pourra alors publier des codes d invitation qui permettront l accès à l application web. Les usagers pourront envoyer leurs problèmes/commentaires à travers un formulaire simple qui sera transmis à l équipe. B. Résultats des tests La couverture du code est un indicateur relativement fiable de la qualité et de la quantité des tests. L équipe peut alors s assurer que le fonctionnement des tests équivaut au fonctionnement général des différents modules. L application Web contient actuellement 842 lignes de code effectives (lignes contenant au moins une instruction), dont 743 sont couvertes par les tests, pour un pourcentage de couverture de 88,42%. A. Conclusions IV. Conclusions et travail futur Le covoiturage québécois et nord-américain sont des domaines qui démontrent encore beaucoup de potentiel. Comme l a fait Amigo Express il y a 6 ans, le projet LzGo cherche à exploiter les lacunes des solutions présentement offertes. L application Web, bâtit sur Ruby on Rails, offrira bien sûr les fonctionalités de base des systèmes de covoiturage : annoncer des départ et s incrire sur un départ. Cependant, LzGo en fera bien plus aussi : la plateforme misera sur les applications mobiles et une intégration significative avec les médias sociaux pour assurer une expérience plus simple, plus sociale et plus accessible aux utilisateurs. Voilà donc pourquoi tous les volets de la solution sont importants : chaque module complète le casse-tête pour créer une plateforme cohérente. Étant donné l importance de l expérience utilisateur, certains choix technologiques ont été décidés en conséquence. Les application mobiles, par exemple, sont développées dans leurs environnements natifs plutôt que d utiliser un framework à multiples déploiements. Aussi, une infrastructure qui favorise la redondance sera de mise pour assurer un service de qualité, même lors des périodes chargées. La stratégie de test donne la possiblité de développer en intégration continue. Les tests unitaires, fonctionnels et d intégration permettent de voir les régressions et de les corriger avant qu ils affectent le développement des autres.

6 B. Leçons apprises Le projet LzGo offre un apprentissage constant à tous les membres de l équipe. Que ce soit du point de vue technique ou du point de vue de gestion de projet, les leçons apprises sont nombreuses. En voici quelques-unes. Il est important d avoir l avis de tous les membres lors des sprints planning. Ceci assure des sprints plus réalisables. Il faut absolument prioriser les fonctionalités du backlog au départ et ne pas avoir peur d en couper. Malgré avoir planifié du temps pour le ramp up de l équipe, le fardeau de travailler dans un nouveau langage est tout de même considérable. Mettre l emphase sur l expérience utilisateur force à faire des choix technologiques qui sont parfois coûteuses en terme d heures de travail. C. Développements futurs Plusieurs avenues s ouvrent à la plateforme LzGo pour assurer la bonne continuité de la solution. Premièrement, un travail de réusinage sera nécessaire dans tous les modules afin d assurer une meilleure longévitée au projet. Étant donné que le projet sera actif à long terme, il est essentiel d assurer que celui-ci soit maintenable et extensible. Deuxièmement, l équipe devra se pencher sur le développement de l application Android. Il faudra répliquer toutes les fonctionalités offertes sur la plateforme ios tout en assurant la meilleure expérience utilisateur possible. Troisièmement, plusieurs idées ont été lancé pour des nouvelles fonctionnalités. Quoiqu il reste toujours des analyses à effectuer, il est tout à fait possible d étendre la solution courante pour mieux accomoder autres scénarios de covoiturage. Finalement, une poussée constante en réglage de bogues sera nécessaire avant et après le lancement afin de s assurer, encore une fois, de la meilleure expérience utilisateur possible. Quoi qu il en soit, il est certain que le futur du projet sera une combinaison de ces lignes directrices. Acknowledgment L équipe LzGo aimerait remercier l équipe professorale de S7 de l Université de Sherbrooke, ainsi que le Département de Génie Électrique et Informatique pour leur soutien tout au long du développement de LzGo. Références [1] Apple. (2012) Human interface guidelines. [Online]. Available : https ://developer.apple.com/library/ios/documentation/userexperience/ conceptual/mobilehig/introduction/introduction.html [2] 37Signals. (2012) Ruby on rails homepage. [Online]. Available : http ://rubyonrails.org [3] J. Cheung and M. Bleigh. (2010) Grape rest-like api microframework. [Online]. Available : http ://intridea.github.com/grape/ [4] (2012) Mysql : : The world s most popular open source database. [Online]. Available : https :// [5] (2012) Git. [Online]. Available : http ://git-scm.com/