Etude et développement des applications RTLNet

Transcription

1 Ecole Centrale Marseille RTLNet Paris, France Travail de Fin d Etudes Du 2 avril au 27 septembre 2013 Etude et développement des applications RTLNet Angela Prestaux 3ème année promotion 2013 Parcours S2I Tuteur école : François Brucker Tuteur entreprise : Damien Bourdette 1

2 Remerciements En premier lieu, je remercie Tristan Jurgensen, le directeur général de RTLNet, de m avoir accueillie dans son entreprise. Je tiens particulièrement à remercier Damien Bourdette, mon tuteur entreprise, pour son accompagnement et sa patience tout au long de celui-ci. Un grand merci également à Olivier, Thomas et Cédric, mes collègues de bureau, pour leurs explications et leur bonne humeur. Je remercie aussi Sébastien Bisch et Michel Depeige qui m ont toujours expliqué de bon coeur le fonctionnement de la maison RTL, du robot de stockage longue durée aux studios d enregistrement. Enfin, je remercie toutes les personnes qui ont contribué à faire de ce stage une expérience agréable et enrichissante. 2

3 Résumé / Abstract RTLNet est la filiale digitale de l entreprise RTL, qui s occupe du développement et de la maintenance des applications Web du groupe, que ce soit les portails Web ou les produits internes. Lors de mon stage, j ai pu participer au développement d un nouveau produit de la phase d expression du besoin à la mise en production, mais aussi au développement de nouvelles fonctionnalités sur des produits déjà existants. Les produits sont essentiellement basés sur le langage Java et le framework Spring MVC. L équipe de développement dispose néanmoins d une liberté technique qui leur permet d expérimenter régulièrement de nouvelles technologies, comme les outils GWT ou le langage Groovy. RTLNet is the digital subsidiary of the company RTL, the first radio broadcaster in France. RTLNet deals with the development and support of the group web applications, web portals for the radio stations or backoffice products. During my internship, I took part in the development of a brand-new product, from the specification phase to its actual production deployment. I was also involved in the development of new features and bug resolving in the existing projects. RTLNet s applications mainly rely on the Java programming language and the Spring MVC framework. The team of developers nevertheless enjoy a technical liberty which allows them to try many different technologies, such as GWT or the Groovy programming language. 3

4 Mots-clé Agilité - SCRUM - Lean - Déploiement continu - Intégration continue - Xtreme Programming - Tests unitaires Java - Spring MVC - Groovy - GWT - MongoDB 4

5 Glossaire Framework : (littéralement cadre de travail ) ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d une partie d un logiciel. Design pattern : (littéralement patron de conception ) arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d'un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels. Inversion de contrôle (IoC) : il s agit d un design pattern commun à tous les frameworks, qui stipule que le flot d exécution de l application n est pas sous contrôle direct de l application mais que c est le framework lui-même qui gère les liens entre les objets. Le principe est de découpler les liens de dépendances entre objets. 5

6 A. L entreprise : RTLNet 1. RTLNet : une filiale de RTL 2. Le rôle de RTLNet 2.1 Organigramme 2.2 Espace de travail 3. Produits 3.1 Portails 3.2 Les sites thématiques 3.3 Les produits backoffice 4. Architecture applicative 4.1 Infrastructure 4.2 Monitoring 4.3 Trafic 4.4 RTLNet dans le paysage technologique Web B. Organisation et pratiques 1. Organisation : processus Agile 1.1 Origines diverses 1.2 Manifeste Agile 1.3 Dans la pratique 1.4 Outil utilisé : Jira/GreenHopper 2. Le développement par les tests 2.1 Une pratique Agile 2.2 Limites 2.3 JUnit 2.4 Mocking 3. Design & refactoring 4. Principes & lois 5. Intégration continue 5.1 Principe 5.2 Outil

7 6. Déploiement continu 6.1 Principe 6.2 Outils 7. Vue d ensemble C. Projets 1. Participation aux projets RTLNet 2. Application mobile : Snappy 2.1 Contexte 2.2 Modèle de données 2.3 Communication avec une application externe 2.4 Distribution 2.5 Conclusion 3. La consommation des players : tic.rtl.fr 3.1 Contexte 3.2 Fonctionnement général d une application de tracking 3.3 Challenge technique 4. Nouveau site thématique : pronostics.rtl.fr 4.1 Contexte 4.2 Modèle de données 4.3 Algorithmes 4.4 Prototype 4.5 Conclusion 5. Refonte du CMS interne : revo.rtl.fr 5.1 Contexte 5.2 Outil utilisé : GWT 5.3 Programmation Orientée Aspect 5.4 Flat design 5.5 Fonctionnalités HTML Conclusion

8 Introduction Ce stage au sein de RTLNet m a été proposé à la suite de mon projet de filière S2I, qui consistait en l élaboration d un moteur de recommandations de contenu pour le site de Fun Radio. J ai ainsi eu l occasion d intégrer l équipe de développement backend, d observer leur processus de travail et de me former aux technologies qu ils utilisent. L équipe à effectif réduit (4 personnes) produit et maintient plus de 20 produits, ce qui offre une grande variété dans les problématiques rencontrées ainsi que dans les solutions techniques adoptées pour répondre à ces problèmes. Ce stage m a également donné un aperçu des challenges techniques particuliers aux sociétés de média comme une station de radio : la mesure de leur audience ou la distribution de leurs contenus par exemple. 8

9 A. L'entreprise : RTLNet 1. RTLNet : une filiale de RTL RTL est une station de radio généraliste nationale privée française, créée en Elle est régulièrement designée comme la première radio française en terme d audience par les sondages Mediamétrie. La radio et ses filiales comptent plus de 460 collaborateurs pour 3 antennes : RTL, RTL2 radio pop-rock ciblant les jeunes adultes et FunRadio, radio au son dancefloor visant essentiellement les jeunes. RTL France est une filiale à 100 % du groupe de média RTL Group, qui fait lui-même partie du groupe multinational Bertelsmann. Organigramme Pole Radio RTL RTL compte également 3 marques filiales : IP France, la régie publicitaire, MediaPanel, la filiale de recherche stratégique et musicale et enfin RTLNet, la filiale digitale dans laquelle j ai effectué mon stage. 9

10 2. Le rôle de RTLNet RTLNet est la filiale digitale de RTL, fondée en 2000, elle compte plus de 30 salariés. Créée à l origine pour éditer les sites du groupe (rtl.fr, rtl2.fr et funradio.fr), l entreprise gère maintenant plus de 20 applications différentes. 2.1 Organigramme Organigramme RTLNet Le pole développement de RTLNet se compose de : - l équipe système, qui maintient les serveurs d application. L équipe n est pas uniquement dédiée à RTLNet. Elle ne maintient les serveurs que d une partie des applications RTLNet : une grande partie des services systèmes & réseaux nécéssaires a été externalisée il y a 2 ans. 10

11 - l équipe de développement frontend, le studio, qui s occupe de la conception graphique des portails et de la réalisation HTML/CSS et Javascript des projets. - l équipe de développement backend, au sein de laquelle j ai effectué mon stage. Elle s occupe de l architecture, du developpement et du maintien des applications. La technologie utilisée majoritairement est Java, avec le framework Spring MVC. Les tâches de l équipe de dévéloppement sont initiées par des sources diverses : - l antenne (portails des radios, outil en ligne de tracking des sons diffusés) - la rédaction web (correction de bugs sur les sites et sur le gestionnaire de contenus) - les équipes marketing (tracking du trafic des sites, intégration de contenu partenaire) - les éditeurs (proposition de nouvelles fonctionnalités sur les portails, et de nouveaux sites thématiques) 2.2 Espace de travail Les locaux de RTLNet se situent dans l immeuble de RTL, 22 rue Bayard à Paris (8ème). C est au même endroit que sont enregistrées les émissions des trois radios de la marque. Studio d enregistrement RTL Le bureau des développeurs est un open space au 4ème étage, où tous les développeurs backend travaillent. La chef de projet se trouve dans le même bureau que le DSI (Directeur des Systèmes d Information) au rez-de-chaussée, avec les bureaux des équipes systèmes et réseaux. L open-space des développeurs frontend se situe à l étage en-dessous de celui du backend, ce qui permet de communiquer assez facilement en face-à-face en cas de besoin, les deux équipes travaillant souvent en collaboration. 11

12 Bureau des développeurs Des outils de monitoring ont été installé, afin de pouvoir suivre en temps réel l état des applications et leur trafic : - un écran affiche un roulement sur plusieurs pages du produit de suivi du trafic maison, appellé otto. Ces pages présentent entre autre des graphiques avec les articles les plus lus ou les podcasts les plus téléchargés. - un autre écran est rélié à Jenkins, un outil d intégration continue directement relié à l outil de versionnement des sources GitHub. Cet écran est rouge lorqu un projet ne build pas, ou que sa suite de tests ne passe pas totalement. - un feu tricolore permet également de voir en un coup d oeil la santé du repository Git. Ecrans de monitoring 12

13 3. Produits L équipe de développement de RTLNet se charge du développement et du maintien de plus de 20 applications web. Celles-ci peuvent être classées en 3 grandes catégories : 3.1 Les portails Il s agit des sites les plus connus, associés directement à une marque de l antenne : et On peut également mentionner le portail de la régie publicitaire du groupe. Il arrive de temps en temps qu un site soit réalisé pour un grand évènement de l antenne, comme poprockparty.rtl2.fr. 3.2 Les sites thématiques Il s agit de sites dédiés à un thème bien particulier, ils sont parfois réalisés en partenariat avec un sponsor. Il existe ainsi un site dédié à l astrologie, astro.rtl.fr, ainsi qu un site dédié à l automobile, auto.rtl.fr. Le site onrefaitlescourses.rtl.fr est une application de concours de pronostics sur des courses hippiques, qui a été réalisé en partenariat avec le PMU. La participation est gratuite et les meilleurs joueurs peuvent remporter des cadeaux. 3.3 Les produits backoffice Il s agit des produits à l usage exclusif du personnel RTL. Le plus important est le gestionnaire de contenus (ou CMS, Content Management System), revo.rtl.fr. Il comporte plus de 30 modules, qui permettent par exemple aux journalistes d écrire leurs articles pour les portails, aux éditeurs d éditer directement le contenu des certaines pages des sites ou aux équipes marketing d insérer leurs liens de tracking sans passer par l équipe de développement. otto (otto.rtl.fr) est une application qui effectue des statistiques sur les articles les plus lus, les podcasts les plus téléchargés, etc... Chronos (chronos.rtl.fr) est un planificateur de tâches, une sorte de cron 1 permettant de lancer des jobs à intervalles réguliers sur toutes les applications. Il permet par exemple de mettre à jour les données en base qui viennent de flux externes. 1 Programme qui permet d éxécuter automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiées à l avance, ou selon un cycle prédéfini ( 13

14 4. Architecture applicative 4.1 Infrastructure Architecture Tout le trafic des applications passe à travers un load balancer et un serveur de cache Varnish. Le load balancer permet de répartir les requêtes HTTP entre les trois serveurs de production jfront. Varnish ( permet de cacher entièrement les pages pour une durée prédéterminée, ce qui permet aux sites passant à travers de très bien tenir la charge, car les serveurs ne sont sollicités que lorsque le cache expire. Il est possible de flusher le cache Varnish manuellement, il est également vidé lors des mises à jour de contenus. Les fichiers statiques et les médias sont stockés sur deux serveurs à part, avec un moteur Nginx ( Un script spécial est également installé sur ces serveurs, qui permet de redimensionner les images à la volée afin d améliorer la performance des applications. Les trois serveurs de production jfront comportent, en plus des applications, une base MongoDB. Un des 14

15 serveurs héberge la base primaire et les deux autres hébergent les bases secondaires ou replica sets. Réplication dans MongoDB Les applications n écrivent que sur la base primaire et toutes les modifications sont automatiquement reportées dans les bases secondaires. Les applications peuvent lire indiféremment sur les trois bases, sauf dans certains cas où elles sont forcées de lire la base primaire car il faut etre sûr de lire des données à jour. C est le cas du CMS par exemple. Si la base primaire tombe, une des bases secondaires sera automatiquement élue base primaire. Ce système permet ainsi de mieux répartir la charge en lecture des applications, de redonder les données et d offrir une solution de secours en cas de problème avec un des serveurs. Le système de basculement est également utile lors des opérations de mise à jour de la base. Les serveurs de production hébergent également des slaves Solr ( le master étant hébergé sur les serveurs de développements jback. Solr est une base d indexation, répliquée sur un modèle master/slave. Cette technologie permet d effectuer des recherches full-text de manière performante, ce qui est particulièrement pertinent dans le cas du moteur de recherche sur les articles. Solr utilise un procédé de 2 lemmatisation pour indexer son contenu. Enfin, les serveurs de production comportent un bus ActiveMQ ( qui 2 Analyse lexicale du contenu d un texte pour regrouper les mots de même famille. La lemmatisation regroupe les différentes formes que peut revêtir un mot : nom, verbe à l infinif ou conjugué, singulier ou pluriel ( 15

16 implémente la spécification Java Messenging Service, ou JMS. Ce service permet d envoyer des messages entre les applications. Il est par exemple utilisé par le gestionnaire de contenu qui envoie un message capté par le planificateur de tâches Chronos lorsqu un contenu est mis à jour pour que Chronos vide le cache Varnish. L architecture compte également une base de données Oracle redondée. Afin de protéger les données, elle n est pas accessible directement de l extérieur mais uniquement par les serveurs d application. C est le cas également pour les ports de la base de données MongoDB, qui ne sont pas visibles pour les connexions extérieures. 4.2 Monitoring En plus des écrans indiquant la santé des builds, l équipe dispose de deux autres sources d information pour surveiller ses produits. Logstash & Kibana Les logs des serveurs sont collectés et indexés en continu par l outil Logstash ( et sont consultables sur une interface Kibana ( qui permet de faire des recherches dans les logs, de trouver les logs sur une certaine période etc Ces outils sont extrêmement pratiques en cas de problème sur les applications en production, puisqu ils permettent de retrouver facilement les stacktraces des erreurs. Interface Kibana des logs d un serveur de production 16

17 otto est une application maison qui collecte un certain nombre de données business sous forme d évènements envoyés par les portails. Il est ainsi possible de consulter sur cette interface des métriques comme le nombre de vues d un article ou le nombre de téléchargements d un podcast. Interface otto, graphique de présentation des hits articles 4.3 Trafic Le site qui attire le plus de trafic est rtl.fr, avec environ deux millions de visiteurs uniques par mois (ou 5 millions de pages vues). Graphique Google Analytics, on observe une fréquentation entre et 300 pages vues par jour pour RTL Les pages les plus visitées sont la page d accueil et la page du player live, permettant d écouter la radio sur Internet. 17

18 Graphique Google Analytics, pages les plus consultées sur RTL Les portails des deux autres radios de la marque (funradio.fr et rtl2.fr) ont des fréquentations moyennes respectives de 1,5 million et visiteurs uniques par mois. Un site thématique comme onrefaitlescourses.rtl.fr enregistre une fréquentation moyenne de pages vues par jour, pour environ 700 participants réguliers au concours de pronostics. Interface Google Analytics de onrefaitlescourses.rtl.fr, données depuis janvier

19 4.4 RTLNet dans le paysage technologique Web L équipe de développement de RTLNet se tient au courant des évolutions technologiques du monde du Web et utilise globalement des outils récents et reconnus dans le milieu. Nous pouvons le constater en plaçant les technologies utilisées par l équipe dans le techradar ThoughtWorks. ThoughtWorks est une société de consultants réputée, impliquée dans les derniers changements sur le marché du développement logiciel. Ils publient régulièrement sur leur site internet un radar des technologies à adopter/tester/évaluer/abandonner ( Sur celui de Mai 2013, RTLNet utilise : - 5 technologies ou pratiques classées A adopter : ElasticSearch, MongoDB, un processus de déploiement continu automatisé est en place, le studio utilise des frameworks CSS (LESS et SASS). Le passage à l outil de build Gradle est actuellement étudié, en remplacement de Maven. - 3 technologies ou pratiques classées A essayer : Logstash, l utilisation de bases de données NoSQL telles que MongoDB. le design responsive, c est-à-dire qui s adapte dynamiquement au format de l écran de l utilisateur, est progressivement mis en place sur les projets - 2 technologies classées A évaluer : Twitter Bootstrap, une librairie CSS qui permet d avoir un design élégant et unifié sans efforts est utilisé dans tous les projets backoffice et les icons fonts, les icônes sous forme de police de caractères, sont utilisées par le studio. - 2 technologies classées A abandonner : Maven et les tests basés sur un navigateur, tels que Selenium. Les développeurs de RTLNet sont libres de tester les technologies qui les intéressent sur les projets, ce qui permet à l entreprise de ne pas se laisser dépasser dans le domaine, et on observe en effet que l ensemble des technologies utilisées sont globalement récentes et à la pointe de ce qui se fait. L équipe cherche effectivement des solutions de remplacement aux technologies classées A abandonner. Gradle est notamment en cours d évaluation pour remplacer Maven. 19

20 B. Organisation et pratiques Le travail quotidien de l équipe de développement est organisé grâce à une méthodologie Agile. Cette méthodologie implique la mise en place de processus de tests, d intégration et de déploiement continus qui assurent un niveau de qualité et de confiance dans le code produit. 1. Organisation : processus Agile 1.1 Origines diverses L équipe de développement a adopté une organisation de travail basée sur la méthodologie Agile. La méthode en place est une méthode Scrum (réference bibliographique [4]) teintée de principes venant de l approche Lean et de XP (Xtreme Programming, référence bibliographique [3]). L idée est de développer sur des cycles courts appellés itérations (dans notre cas des périodes de deux semaines) avec des mises en production fréquentes, dès qu une fonctionnalité est implémentée. Cette méthode procure une plus grande souplesse aux demandeurs. En effet, ils ont la possibilité de voir le travail avancer presque en temps réel, ce qui n est pas possible avec les méthodologies plus classiques type cycle en V où la livraison se fait en un bloc. Ainsi, il est beaucoup moins coûteux d ajouter une fonctionnalité qui aurait pu être oubliée ou de faire des modifications. On évite les longues phases de spécifications et d écriture de documentation en début de projet pour privilégier le prototypage et la technique des tracer bullets : commencer rapidement le code de manière à affronter les problèmes concrets rapidement. Il est ainsi possible de découvrir et isoler les éventuels points délicats en début de projet (référence bibliographique [2]). 1.2 Manifeste Agile Ces principes s appuient sur les grandes lignes du manifeste Agile, rédigé en 2001, qui a dégagé 4 valeurs principales pour mettre en place un développement applicatif plus centré sur les demandeurs et leurs besoins. Manifeste Agile ( 20

21 1.3 Dans la pratique Le travail est planifié suivant la méthodologie Scrum. Lorsqu ils souhaitent un travail de développement (résolution d un bug, modification d un produit existant ou création d un nouveau produit), les demandeurs doivent ouvrir un ticket spécifiant leur besoin. Ce ticket passe en backlog (liste d attente) : la demande sera étudiée lors de la prochaine réunion de priorisation. Méthode Scrum Cette réunion se tient à la fin de chaque itération, toutes les deux semaines. On y décide de l ensemble des tickets qui seront traités lors de la prochaine itération. Elle rassemble : - le responsable de l équipe de développement - le responsable du studio - la chef de projets de la DSI - le directeur général de RTLNet - les responsables des pôles demandeurs, notamment les directeurs éditoriaux et de la rédaction Elle apporte de la visibilité à tous les acteurs de l entreprise sur ce qui est fait par l équipe de développement et pourquoi. Le dialogue est également facilité entre les équipes techniques et éditoriales. A la fin de cette réunion, le ticket reçoit un statut : - Ouvert dev : des développeurs vont travailler dessus - Etude en cours demandeur : mis en attente par manque de détail - Ne sera pas résolu : la demande est refusée Préalablement à chaque réunion, l équipe de développement et le studio doivent charger les tickets, c est-à-dire estimer, dans une unité arbitraire assimilée au jour-homme, le temps nécessaire à sa résolution. Cette partie est assez délicate, en particulier sur les gros projets. C est l expérience et une bonne connaissance des 21

22 produits qui permettent de faire des estimations de plus en plus fiables. Avec ces charges, il est donc théoriquement possible de décider d un nombre de tickets qui devraient pouvoir être traités sur une période de deux semaines. Pour les gros projets, comme la création d une nouvelle application, le ticket est sous-divisé en plusieurs tickets correspondant chacun à une tâche. Ces tickets peuvent être répartis sur plusieurs itérations, avec un produit livré à la fin de chaque. Il est ainsi possible d affiner le besoin et les estimations de charge de travail à chaque itération. En cas de bug ou de modification mineure peu impactante en terme de charge de travail pour les développeurs, un ticket peut passer directement dans l itération en cours. Après plusieurs années de pratique, l estimation de charge est plutôt précise mais la tenue des délais dépend aussi parfois d acteurs externes, des partenaires ou d autres services de l entreprise. S il reste des tickets à la fin de l itération, ils sont remis dans l itération suivante. 1.4 Outil utilisé : Jira/GreenHopper Il s agit d une interface qui permet à la fois de créer les tickets et de les visualiser sous forme d un tableau 3 Kanban. Tous les collaborateurs peuvent se connecter à cette interface avec leur compte entreprise, et peuvent ainsi ouvrir des tickets et suivre l évolution de leurs demandes. Les communications entre les demandeurs et les développeurs pour chaque ticket se font essentiellement à travers l interface de commentaires de chaque Jira. L interface est également connectée à GitHub, l outil de contrôle de version en ligne, ce qui permet d associer chaque ticket aux modifications de le code liées. Cela facilite grandement le processus de relecture du code par un pair, avant la mise en production. 3 Tableau de gestion des tâches inspiré des méthodologies Lean dans l industrie ( 22

23 Le tableau Kanban dans l interface GreenHopper Le tableau est partagé entre le studio et le développement backend : - les trois colonnes de gauche ( A faire studio, A faire maquette et En cours studio ) correspondent au flux de travail frontend. Les tickets qui nécéssitent un travail graphique sont donc placés dans la colonne A faire studio et lorsque les graphistes et intégrateurs ont fini leur travail, ils ferment le ticket ou le passent dans la colonne A faire dev si du travail de développement côté serveur est également requis. - la colonne A faire dev correspond à la liste des tickets qui doivent être réalisés par l équipe de développement backend pendant l itération - la colonne En cours dev liste les tickets qui sont en cours de résolution. Lorsqu un développeur prend en charge un ticket il passe donc le ticket dans cette colonne. Il doit également se l attribuer, c est-à-dire inscrire sur le tableau qu il est la personne en charge de la résolution. En un seul coup d oeil sur le Kanban il est ainsi possible de savoir qui fait quoi à un instant donné. - la colonne Sur le lab liste les tickets théoriquement résolus. Les développements engendrés ont été deployés sur l environnement de test, le lab, ce qui permet aux demandeurs d aller vérifier si leur problème de départ à été effectivement résolu. - la colonne Revue effectuée liste les tickets pour lesquels les développements ont été vérifiés par un autre développeur que celui ayant résolu la demande. Cette étape est systématique pour tous les tickets avant leur mise en production. 23

24 - la colonne En production et Résolu, dans laquelle on retrouve tous les tickets fermés de l itération, après leur mise en production. 2. Le développement par les tests 2.1 Une pratique Agile Le développement par les tests est une technique de développement qui préconise d écrire en premier lieu des tests unitaires avant de commencer à coder la fonctionnalité à proprement parler. Cette technique et ses bénéfices sont développés dans le livre référence de Kent Beck (référence bibliographique [1]).Procéder de cette manière permet dans un premier temps de mieux spécifier ce que l on cherche à accomplir. Les tests font office de fil rouge, qui permet au développeur de toujours tendre vers un but concret : faire passer les tests. Les tests servent également de documentation pour les autres développeurs : s il veulent savoir à quoi sert une fonction, aller regarder ses tests unitaires permet de découvrir son but ainsi que ses cas limites. Enfin, l avantage majeur du recours aux tests unitaires est qu ils permettent d assurer un standard de qualité pour les applications. Ainsi, les développeurs peuvent se permettre de faire de grandes modifications dans le code, comme des refactorisations, sans avoir peur de provoquer un bug par inadvertance. Red / Green / Refactor Kent Beck Le motto du développement par les tests est donc d écrire d abord un test qui rate (test rouge), pour le faire ensuite passer (test vert) et ensuite s atteler à la refactorisation, c est-à-dire écrire un code de meilleure qualité (nom de variable plus explicite, mise en commun d éléments de logique ) tout en gardant la même fonctionnalité. Les tests représentent un filet de sécurité lorsque l on modifie le code. 2.2 Limites Cependant, malgré leur forte valeur ajoutée, les tests ne garantissent pas l absence de bug dans le code. Ils assurent que dans les scénarios d utilisation envisagés et retranscrits sous forme de tests, l application se comporte comme on s attend à ce qu elle le fasse.. Program testing can be used to show the presence of bugs, but never to show their absence! Edsger W. Dijkstra 24

25 Un problème récurrent de l équipe de développement RTLNet était notamment les échecs à répétition des tests d interface Selenium. Selenium est un framework de test qui pilote un navigateur Web. Il permet par exemple de simuler un clic sur un bouton et de vérifier que les changements de structures dans l arbre DOM qui s ensuivent sont bien ceux attendus. Framework de test Selenium Cependant, sur les pages lourdes à charger comme celles de RTL (notamment à cause des blocs de publicité des partenaires) les tests échouent souvent en timeout : la clause de test attendait une réponse plus rapide que le temps de chargement de la page. Les tests Selenium sont des tests assez fragiles qui cassent facilement, après le moindre changement de structure dans la page. RTLNet songe à les abandonner, car s habituer à avoir des tests en erreur risque de masquer un éventuel problème important sur les applications. 2.3 JUnit En Java, le principal framework pour écrire des tests unitaires est JUnit. Il permet d écrire des suites de tests unitaires et de les lancer simplement, d autant plus qu il est intégré nativement dans de nombreux IDEs, dont IntelliJ, utilisé à RTLNet. Des modules complémentaires permettent également de faciliter l écriture des tests, comme le module FEST Assertions qui permet d écrire les assertions avec une syntaxe proche du langage naturel. import org.junit.test; import static org.junit.assert.*; public class TestAssertions public void testassertions() { String str1 = new String ("abc"); String str2 = new String ("abc"); String str3 = null; String str4 = "abc"; String str5 = "abc"; int val1 = 5; int val2 = 6; String[] expectedarray = {"one", "two", "three"}; String[] resultarray = {"one", "two", "three"}; //Check that two objects are equal assertequals(str1, str2); //Check that a condition is true 25

26 asserttrue (val1 < val2); //Check that a condition is false assertfalse(val1 > val2); //Check that an object isn't null assertnotnull(str1); //Check that an object is null assertnull(str3); //Check if two object references point to the same object assertsame(str4,str5); //Check if two object references not point to the same object assertnotsame(str1,str3); //Check whether two arrays are equal to each other. assertarrayequals(expectedarray, resultarray); } } Assertions JUnit int removed = employees.removefired(); assertthat(removed).iszero(); List<Employee> newemployees = employees.hired(today); assertthat(newemployees).hassize(6).contains(frodo, sam); assertthat(yoda).isinstanceof(jedi.class).isequalto(foundjedi).isnotequalto(foundsith); Assertions FEST Avoir des tests unitaires faciles à écrire et à comprendre incite également à avoir un code bien découplé, ce qui est bénéfique pour l application. L idéal est de pouvoir tester morceau par morceau, et d éviter l imbrication au maximum pour qu en cas de problème, la source de l erreur soit évidente. Pour tester des applications construites sous forme de modules et de services suivant cette philosophie, on peut utiliser des mocks. 2.4 Mocking Les mocks sont des objets de tests qui remplacent les véritables objets utilisés dans l application, et auxquels on peut dicter de manière autoritaire le comportement lors de chaque test. En effet, on peut avoir besoin de faire interagir les objets qu on teste avec d autres objets ou services, mais sans vouloir tester ces objets-là en même temps. On peut alors simuler leur comportement, en forçant des mocks à répondre ce que l on voudrait que le véritable objet réponde dans les circonstances testées. Savoir si l objet mocké répondrait réellement ce que l on attend est le sujet d une autre suite de tests. 26

27 Mockito est un framework Java qui permet de mettre en place cette technique. import static org.mockito.mockito.*; import static public void iteratorwillreturnhelloworld(){ //arrange Iterator i=mock(iterator.class); when(i.next()).thenreturn("hello").thenreturn("world"); //act String result=i.next()+" "+i.next(); //assert assertequals("hello World", result); } Exemple de mock avec Mockito 3. Design & refactoring Dans les projets RTLNet, l idée est de commencer rapidement à coder dès que le minimum d information nécessaire est disponible sur le produit. Le code est ensuite modifié au fil des changements dans l expression du besoin et des discussions avec le client du projet. Même après la sortie d un projet, son code peut être repris et parfois beaucoup changé, selon les retours des utilisateurs et l évolution du besoin du client. Commencer rapidement avec du code ne veut pas dire qu il n y a pas de réflexion sur l architecture de l application, mais au contraire que cette réflexion est continue sur toute la vie du produit et non pas cantonnée à une seule phase de spécifications au début du projet (référence bibliographique [5]). Don't worry about design, if you listen to your code a good design will appear. Martin Fowler Cette grande souplesse est permise par la présence de tests unitaires qui constituent une sorte de filet de sécurité et assurent au développeur que l application est toujours fonctionnelle après ses changements. 27

28 4. Principes & lois - La règle du boy-scout Il s agit d une règle simple qui incite à se placer dans une démarche d amélioration continue : Toujours laisser un endroit dans un meilleur état que celui dans lequel vous l avez trouvé. En pratique, cela signifie que lorsque l on modifie un morceau de code, il ne faut pas hésiter à procéder aux améliorations qui nous semblent possibles même si elles ne sont pas strictement nécessaires. On obtient ainsi globalement un code de meilleure qualité petit à petit. - Law of Demeter ou principe de connaissance minimale Un objet devrait faire aussi peu d'hypothèses que possible à propos de la structure de quoi que ce soit d'autre, y compris ses propres sous-composants. En particulier, un objet doit éviter d'invoquer des méthodes d'un objet retourné par une autre méthode. On l appelle également la règle du point de manière simplificatrice, en disant qu il faut le moins de points possible (c est-à-dire d appel à un getter) pour éviter une trop grande interdépendance entre les objets. En effet, plus les objets connaissent en détail un autre et s appuient sur cette connaissance pour construire leurs propres méthodes, plus le code cristallise et devient difficile à modifier simplement. - Hollywood principle Il s agit d un principe basé sur la réponse classique aux castings hollywoodiens : Don t call us, we ll call you - Ne nous appelez pas, nous vous appelerons. C est un principe particulièrement pertinent dans le cas d un programme qui doit respecter les contraintes d un framework, le développeur ne maîtrise pas le flux de l application de A à Z mais doit implémenter des interfaces et enregistrer ses composants, qui seront appellés lorsque nécessaire. Ce principe est très important dans le cas de framework à inversion de contrôle, où les liens entre les composants sont décidés par des fichiers de configuration lors de l exécution. - Simple responsability principle Ce principe indique qu une classe dans un programme orienté objet ne devrait avoir qu une seule responsabilité, et prendre en charge la totalité de cette responsabilité. Ainsi, lorqu on veut modifier l aspect d un programme il suffit de modifier une seule classe, ce qui ne risque pas de casser une autre fonctionnalité. - Don t Repeat Yourself (DRY) Chaque représentation de savoir doit être unique dans un programme, il faut éviter la duplication de code pour faciliter le maintien de l application en cas de changement dans la logique. 28

29 - You Ain t Gonna Need It (YAGNI) Lorsqu on développe une fonctionnalité, il ne faut pas ajouter de code inutile immédiatement en prévision du développement d une autre fonctionnalité qui n est pour l instant pas demandée : il y a de grandes chances que ce code reste inutilisé. Lorsqu une fonctionnalité supplémentaire est effectivement demandée, on ajoutera du code là où c est nécessaire. 5. Intégration continue 5.1 Principe Un processus d intégration continue est mis en place : il s agit d un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée. Pour appliquer cette technique, il faut d'abord que : - le code source soit partagé, grâce à un outil de versionnement. RTLNet utilise Git, les projets sont hébergés sur la plate-forme GitHub, mais ne sont pas visibles par le public comme le sont habituellement les projets GitHub open-source. - les développeurs intègrent (commit) au moins quotidiennement leurs modifications, afin de ne jamais avoir sur son poste en local une version de l application totalement différente de celle partagée, ce qui pourrait arriver en travaillant plusieurs jours, voire semaines, sans se resynchroniser avec les autres. - des tests soient inclus dans les projets pour valider l application. 5.2 Outil Un outil d intégration continue permet ensuite de récupérer automatiquement le code lorsqu une modification est poussée sur le repository GitHub, de lancer un build afin de vérifier que l ensemble du code compile correctement, puis de lancer la suite de tests. RTLNet utilise Jenkins. Ce processus permet de tester immédiatement les unités modifiées. Ainsi, il est possible de détecter rapidement le code incompatible, manquant ou erroné. Les problèmes d'intégration étant détectés et réparés de façon continue, ils ne sont pas accumulés au fur et à mesure du projet. C'est pourquoi il est possible d'effectuer un test ou une démonstration sur une version fonctionnelle, en permanence. De plus, Jenkins déploie automatiquement toutes les applications en environnement de test (le lab) chaque nuit, 29

30 pour s assurer que les applications sont buildées au moins une fois par jour. Panneau de commande de Jenkins 6. Déploiement continu 6.1 Principe Le déploiement continu est un prolongement de l intégration continue, visant à réduire au maximum le temps entre l écriture d une nouvelle ligne de code et l utilisation réelle de ce même code par les utilisateurs finaux. Pour cela, il s agit d automatiser les étapes de la mise en production. Les avantages d une telle pratique sont multiples : le retour sur investissement pour chaque nouveau développement commence plus tôt et il est possible d obtenir très rapidement des retours d utilisateurs sur une nouvelle fonctionnalité. De cette manière, il est possible de tester plusieurs hypothèses afin de retenir celle qui convient le mieux au client. De plus, des déploiements automatisés et réguliers diminuent grandement la peur de la mise en production chez les développeurs. RTLNet a mis en place des outils de déploiement continu de telle sorte qu une mise en production se résume à appuyer sur deux boutons : un pour effectuer un build Maven du projet et un pour effectivement déployer ce tag sur les serveurs de production. 30

31 6.2 Outils Rundeck, console Web L outil utilisé à cette fin est Rundeck, une console Web qui permet de lancer des scripts sur différents serveurs, considérés comme les noeuds d un réseau. L équipe a développé un ensemble de scripts en Groovy qui sont donc exécutés par cette application sur les serveurs visés (lab ou production). Interface de Rundeck Groovy est un langage qui se prête particulièrement bien aux scripts de par ses facilités d écriture qui le rendent particulièrement agréable à utiliser. Le script de déploiement est unique pour toutes les applications et s appuie sur un fichier de configuration en YAML, créé lui pour chaque projet. Ce script spécifie notamment le port utilisé sur le serveur ou la taille allouée pour la permgen, l emplacement mémoire utilisé par la JVM (Java Virtual Machine) pour stocker les définitions de classes. Cet emplacement ne bénéficie pas du ramasse-miettes, et en cas de dépassement de la taille définie, l application lance une exception OutOfMemoryError. Pour les gros projets, il faut donc définir un espace plus grand que les 64MB définis par défaut, par exemple pour rtl.fr, la permgen est fixée à 256MB. 31

32 def deploywebapp(string version, String tomcatconfresolver) { mkdirs() assertexists() log "Deploying $name $version" intempdirectoy { File tempdir > def war = new File(tempDir, "ROOT.war") new NexusArtifact(name: name, version: version, extension: 'war').downloadto(war) stoptomcat() updatetomcatconf(version, tomcatconfresolver) new File("$webappDir/webapps").deleteDir() new File("$webappDir/work").deleteDir() new File("$webappDir/webapps").mkdirs() new File("$webappDir/work").mkdirs() log "Copying war to $webappdir/webapps/root.war" new AntBuilder().move(file: war, tofile: new File(webappDir, "webapps/root.war"), overwrite: true) starttomcat() }} Extrait du script de déploiement Groovy port: serverport: xms: 256m xmx: 2048m maxpermsize: 256m monitoringpaths: '/,/secured/monitoring/version' monitoringuserpasswd: user:password YAML de configuration Lorsqu on lance un tag Maven avec Jenkins, l artefact obtenu est automatiquement poussé vers un serveur Nexus ( qui stocke tous les builds. C est sur ce serveur que le script Groovy va chercher l application à déployer. La gestion des serveurs en dehors des applications (installation des bases de données, mise à jour des machines virtuelles etc ) est déléguée à BCS, le prestataire en charge de la partie système et réseaux. L outil Puppet ( est utilisé à cette fin. Puppet 32

33 Puppet est un outil de gestion de configuration, qui fonctionne sur les environnement Unix et Microsoft. Il utilise un langage déclaratif : l utilisateur indique l état souhaité de son système dans des Puppet manifests, Puppet se charge ensuite d installer les ressources nécessaires et leurs dépendances sur chaque machine. Cela permet de gérer en un fichier unique des machines pouvant être dans des états très différents au départ. Puppet se définit ainsi en opposition à un système impératif, où l utilisateur doit spécifier ce qui doit être installé sur la machine, ce qui dépend de l état initial de celle-ci. Chef ( est un outil similaire. 7. Vue d ensemble Processus d intégration et déploiement continu Le processus d intégration et de déploiement continu est résumé dans la figure ci-dessus : - en premier lieu, la demande client est exprimée à travers un ticket dans JIRA - si le ticket est accepté lors de la réunion de priorisation, il est résolu par les développeurs - le code produit est versionné dans Github - il est alors automatiquement compilé et testé par Jenkins, le résultat des tests étant relié à des écrans dans le bureau des développeurs afin de détecter rapidement le moindre problème - lorsque les tests et la compilation réussissent, Jenkins envoie un artefact à un serveur Nexus - cet artefact est ensuite disponible pour le déploiement à partir de l interface Rundeck - les logs des serveurs sont enregistrés dans kibana et des statistiques sur leur utilisation sont sauvées dans otto 33

34 C. Projets 1. Participation aux projets RTL Lors de ce stage, j ai participé aux tâches quotidiennes de développement et de maintenance des applications réalisées par l équipe de développement, ce qui m a permis de me familiariser avec de nouveaux concepts et technologies, principalement en environnement Java. Les applications sont majoritairement développées avec le langage Java, qui est un langage de programmation objet à typage fort. C est un langage utilisé de manière étendue dans le monde de l entreprise car il est bien maintenu et surtout développé de manière à assurer la compatibilité entre les versions en permanence. Cela peut présenter des inconvénients car le langage est moins dynamique qu un autre qui s affranchit de ces contraintes - comme Ruby -, mais la perennité du code écrit est assurée. De plus en plus, les tests unitaires et les services Web sont écrits en Groovy, un autre langage s exécutant également sur la JVM (Java Virtual Machine), ce qui permet donc de mélanger dans un même projet des classes Java et des classes Groovy. Le langage Groovy autorise plusieurs facilités d écriture très appréciables, comme les closures, ou le constructeur à paramètres nommés qui augmente de façon importante la lisibilité des tests unitaires. L IDE (Integrated Development Environment, environnement de développement intégré) utilisé est IntelliJ IDEA. C est un éditeur payant très fonctionnel au quotidien. Ses fonctionnalités les plus appréciables sont notamment le gestionnaire de refactorisation, très complet, et le moteur de recherche d usage pour une fonction. Il dispose également de multiples plugins. 4 La majorité des projets est réalisée avec le framework Spring MVC. Spring est un conteneur dit léger car les classes n ont pas besoin d implémenter une interface pour être prises en compte (contrairement aux serveurs d applications J2EE), la création d objets et leur mise en relation se fait à travers un fichier de configuration. 4 Modèle Vue Contrôleur : design pattern répondant au problème de l organisation d une interface graphique. L idée est de bien séparer les données, la présentation et les traitements ( 34

35 La grande force du framework Spring est son implémentation de l inversion de contrôle par injection de dépendance. Les dépendances peuvent s écrire très facilement par annotation public class AdminController private SessionService private DataExtractor private RandomSessions randomsessions; De nombreux modules permettent aussi de traiter des problématiques fréquentes dans les applications, comme Spring Security pour gérer l authentification et la sécurisation. 2. Application mobile : Snappy Nom : Snappy Besoin : Application mobile pour permettre aux journalistes sur le terrain de prendre rapidement une photo, une vidéo ou une séquence audio et de les envoyer accompagnées d un titre et d un texte directement dans le CMS Etat actuel : en cours Technologies utilisées : objective-c, framework Cocoa Touch 2.1 Contexte Snappy est la première application iphone réalisée en interne par les équipes de développement RTLNet, les applications mobiles des radios ayant été sous-traitées à des prestataires spécialisés. Cette application est dédiée à être exclusivement distribuée en interne, aux journalistes - potentiellement des trois radios. Le parc de téléphonie mobile de RTL étant à très grosse majorité composé d iphone 4 et 4S, il a été décidé de développer une application ios 5. Les fonctionnalités demandées étaient assez basiques : pouvoir éditer et sauver un sujet, avec un titre, un peu de texte et la possibilité d ajouter des images, des vidéos et des sons. Un sujet devait ensuite pouvoir être 35

36 envoyé directement sur le gestionnaire de contenu Revo. 2.2 Modèle de données Pour la partie média, nous avons utilisé les frameworks et composants natifs mis à disposition par Apple : AV Foundation pour la gestion des vidéos/sons et le composant UIImagePicker pour l accès à la librairie de photos de l iphone, ainsi qu à sa caméra. Pour la partie persistence des données, nous avons utilisé le framework CoreData, qui fournit une interface de persistence directement couplée à une base locale SQLite. Il est alors très aisé de sauvegarder un objet après avoir mis en place un contexte de persistence dans l application : //Instancier l object dans le contexte de persistence NSEntityDescription *entity = [NSEntityDescription entityforname:@"subject" inmanagedobjectcontext:context]; Subject* subject = [[Subject alloc] initwithentity:entity insertintomanagedobjectcontext:context]; //Traitement de l objet _subject.title = _txttitle.text; _subject.text = _txttext.text; _subject.medias = [[NSOrderedSet alloc] initwitharray:_medias]; //Sauvegarde NSError *error = nil; NSManagedObjectContext *managedobjectcontext = self.managedobjectcontext; if (managedobjectcontext!= nil) { if ([managedobjectcontext haschanges] &&![managedobjectcontext save:&error]) { NSLog(@"Unresolved error %@, %@", error, [error userinfo]); abort(); } } Le modèle de données se définit directement dans XCode, l IDE dédié développé par Apple. Le modèle de données que nous avons utilisé pour Snappy est le suivant : Un objet Subject contient toutes les données du formulaire (titre et texte), ainsi que la date de création et la date de publication (ce qui est utile pour la fonctionnalité qui supprime au démarrage de l application tous les sujets 36

37 publiés depuis plus de 7 jours). Cet objet possède également une relation de type one-to-many avec des objets Medias, correspondant logiquement aux médias attachés. Cet objet contient uniquement le type du média, utilisé pour déterminer le type d affichage utilisé dans l application, ainsi que le chemin absolu du média dans le gestionnaire de fichiers de l application (NSFileManager). L interface utilisateur que nous avons développée utilise très largement les composants natifs ios et s inspire de l interface de l application iphone de Gmail. 2.3 Communication avec une application externe Un autre fonctionnalité demandée pour cette application était la création d un pont permettant à Snappy de recevoir des sons provenant d une autre application du groupe RTL qui permet justement l enregistrement et le montage d extraits sonores. ios définit une zone neutre entre les applications, l UIPasteboard, sur laquelle les applications peuvent déposer des données avec un système de clé-valeur de façon à pouvoir les retrouver ensuite. Il faut donc que l application tierce dépose le son sur l UIPasterboard avec une clé connue - nous avons décidé d utiliser l identifiant de Snappy - et déclenche ensuite l ouverture de Snappy. L ouverture de l application par appel d une certaine URL prédéfinie est une option qu il est possible d activer dans la configuration. Il est ensuite possible de déterminer dans le code si l application a été ouverte directement par l utilisateur ou par une autre application. Dans le cas d une ouverture externe, nous allons donc voir sur l UIPasteboard s il existe des données associées à la clé connue, si oui nous les rapatrions dans Snappy. //méthode appellée lors d une ouverture externe (BOOL)application:(UIApplication *)application openurl:(nsurl *)url sourceapplication:(nsstring *)sourceapplication annotation:(id)annotation { // vérification de la source de l appel if ([sourceapplication hasprefix:@"com.appcoda"]) { // récupération des données 37

38 } UIPasteboard *pasteboard = [UIPasteboard generalpasteboard]; NSData *data = [pasteboard dataforpasteboardtype:@"fr.rtl.snappy"]; if (data) { //ajout des données à l application } } return YES; 2.4 Distribution La distribution de Snappy ne passe pas par l App Store car il ne s agit pas d une application grand public, nous avons donc opté pour une distribution dite Ad Hoc. Il suffit de packager l application sous forme d un fichier.ipa, n importe quel idevice peut ensuite ouvrir ce fichier, qui se comporte comme un utilitaire d installation pour 5 l application. Les.ipa de RTL sont distribués via une page Web protégée par l authentification Active Directory de l entreprise. 2.5 Conclusion Ce projet a permis de diversifier les compétences de l équipe de développement, avec l utilisation de technologies nouvelles. L IDE que nous utilisons habituellement, IntelliJ, n étant pas compatible avec du développement objective-c, nous avons du nous rabattre sur l IDE par défaut XCode. Nous avons alors pu nous rendre compte des limitations des IDEs offrant beaucoup d interfaces graphiques. Si cela présente des avantages en début de développement car il est possible d obtenir rapidement un prototype fonctionnel, ce type d interface se révèle peu pratique lorsque le développement devient plus fin. En effet, il est parfois difficile de trouver l option à activer pour obtenir le comportement recherché alors qu une ligne de code serait plus claire. L interface écrit la configuration dans des fichiers cachés assez obscurs à relire, et il est donc également difficile d écrire du code collaboratif sur ce type de projets car en cas de conflit de version, il est très délicat de réaliser la fusion du fichier à la main. 3. La consommation des players : tic.rtl.fr Nom : tic.rtl.fr Besoin : Mesurer l audience des players live des trois radios, RTL, RTL 2 et Fun Radio. Etat actuel : échec Technologies utilisées : Java, Spring MVC, MongoDB 3.1 Contexte Les mesures d audience sont essentielles dans les métiers de la radio, car ils permettent de négocier le prix des spots publicitaires, la principale source de revenus de l entreprise. Actuellement, les mesures d audience 5 Service centralisé d identification et d authentification à un réseau d ordinateurs utilisant le système Windows, mis en place à RTL 38

39 des players live des 3 radios sont réalisées avec la technologie estat, un produit de la société Mediamétrie. Cette technologie ayant un coût assez élevé, l idée du projet était de construire un prototype d application avec les mêmes fonctionnalités de base qu estat pour tester la faisabilité de réalisation d une solution de remplacement. 3.2 Fonctionnement général d une application de tracking Le modèle de fonctionnement d une telle application est assez simple : lorsque le player se connecte au flux audio, il envoie un POST HTTP sur une adresse de l application qui correspond à un évènement début. 6 L application enregistre cet évènement, et répond avec un cookie qui permet d identifier la session de lecture. Tant que le player est en lecture, il envoie un évènement début à l application à intervalles réguliers. L application qui reçoit l appel vérifie si un cookie est attaché, si c est le cas la session peut alors être identifiée et sa durée d écoute est mise à jour. S il n y a pas de cookie, on en déduit qu il s agit d une nouvelle session. Lors de la première mise en production de l application, nous nous sommes rendus compte qu un nombre conséquent de sessions n étaient pas suivies au-delà du premier évènement début. Nous en avons déduit qu une part non négligeable d utilisateurs n autorisaient pas le stockage de cookies dans leur navigateur. Nous avons donc rajouté une règle de comparaison de l adresse IP pour effectuer le suivi des sessions. Cette règle a ses limites car certains réseaux ont une unique adresse IP de sortie, et donc les sessions de plusieurs utilisateurs peuvent être confondues. C est pourquoi la règle d identification par cookie est prioritaire lorsque celui-ci est présent. Les sessions sont engistrées dans une base MongoDB, particulièrement adaptée pour répondre à ce type de problématique car il est possible de les capper, c est-à-dire de définir une limite haute sur l espace que peut prendre la base. Lorsque cette limite est atteinte, la base remplace les enregistrements les plus anciens par les nouveaux. En effet, le but n était pas de conserver l archive de toutes les connexions au flux audio, mais plutôt de conserver des métriques globales, comme le nombre d utilisateurs connectés simultanément ou la durée moyenne d une session d écoute. Les données brutes étaient donc retraitées régulièrement pour en extraire ces métriques et les présenter sous forme de graphes. 3.3 Challenge technique Lors de sa mise en production, l application a remonté une moyenne de sessions quotidiennes par lecteur, pour une charge sur le serveur autour de 500 requêtes par seconde. L importance du volume de données à entraîné plusieurs problèmes de performance. La première stratégie était de traiter toutes les requêtes en temps réel pour mettre à jour les métriques, ce qui n était pas viable car il fallait plusieurs minutes au serveur pour répondre lorsque l on souhaitait afficher le graphique. Dans un deuxième temps, les événements étaient stockés immédiatement, mais traités de manière asynchrone : nous avons pris la décision de ne plus afficher les données en temps réel mais avec un décalage de quelques heures pour assurer un temps de chargement de la page raisonnable. Cependant, la base de données grossissant de manière non négligable, nous avons été confrontés au problème du stockage dans le temps des données. Finalement, par manque de temps, le projet a été laissé de côté. 6 ou témoin de connexion, suite d informations envoyée par un serveur HTTP à un client HTTP, que ce dernier retourne lors de chaque interrogation du même serveur HTTP 39

40 4. Nouveau site thématique : pronostics.rtl.fr Nom : pronostics.rtl.fr Besoin : Site de concours de pronostics sur les matches de football de Ligue 1 Etat actuel : en production Technologies utilisées : Java, Spring MVC, MongoDB 4.1 Contexte Une des tâches de RTLNet est de produire les sites thématiques de la radio. En se basant sur le principe d un de ces sites ayant réussi à fidéliser son public dans un domaine de niche - les pronostics de courses hippiques avec onrefaitlescourses.rtl.fr - l idée était de proposer un produit similaire dans un domaine plus grand public : le football, et plus particulièrement, le championnat de Ligue 1. Les données nécéssaires concernant le championnat sont fournies par un partenaire, qui met à notre disposition un flux XML avec les rencontres, les joueurs, ainsi que les résultats en temps réel. Un job en cron permet de mettre régulièrement à jour notre propre base de données avec ces informations. 4.2 Modèle de données Selon les règles du jeu, il est donc possible de parier sur les débouchés (égalité, victoire ou défaite de l équipe à domicile) sur tout ou une partie des matches d une journée de championnat. Sur un match par journée, il est également possible de pronostiquer le score, et les buteurs. Cela permet aux joueurs de gagner des points et d être classés en conséquence. Il y a deux types de classements : un classement par manche, qui correspond à 4 journées de championnat et un classement sur toute la saison. Pour répondre à ces règles, le modèle de données mis en place est le suivant : 40

41 Séparer l objet Pari de l objet Rang permet de séparer la partie persistence du formulaire de jeu de la partie calcul des points et classements. Ainsi, en cas de problème dans l implémentation de l algorithme de traitement, il est possible de relancer tous les calculs de points et de classement car les données de départ ne sont pas altérées. L objet Rang contient également un certain nombre de statistiques, comme le nombre total de bons pronostics du joueur sur la période. La référence à la compétition dans les objets du modèle permet d imaginer facilement une extension du jeu à d autres compétitions que la ligue 1, et même à d autres sports que le football. 4.3 Algorithmes Le développement par les tests a été utilisé pour l algorithme de calcul et de classement. Cette technique a été particulièrement appréciée lorsqu il a fallu changer certaines règles du jeu peu après le lancement officiel du site, car elle nous a rassuré sur le fait que nous n avions pas cassé la mécanique du jeu avec nos modifications. public static FootballBetEarnings computeearnings(footballbetpronostic pronostic, FootballGame game, String favoriteteamexternalid) { FootballBetEarnings result = new FootballBetEarnings(); if (game.getresult() == null pronostic == null pronostic.getgameoutcome() == null game.ispostponed()) { return null; } result.setexplanation(game.getliteralfullresult() + " :"); if (game.hasoutcome(pronostic.getgameoutcome())) { result.increaseamount("résultat", game.isgameoftheday()? FootballEarnings.GAMEOFTHEDAY_GAME_OUTCOME : FootballEarnings.GAME_OUTCOME); result.setgoodpronosticcount(1); if (game.hasteam(favoriteteamexternalid)) { result.increaseamount("bonus équipe favorite", FootballEarnings.FAVORITE_TEAM_BONUS); result.increasegoodpronosticcountforfavoriteteam(); } } else { result.increaseamount("résultat", game.isgameoftheday()? FootballBetCharges.GAMEOFTHEDAY_GAME_OUTCOME : FootballBetCharges.GAME_OUTCOME); } if (game.isgameoftheday()) { if (pronostic.hasscore()) { int scoreearnings = FootballBetCharges.SCORE; if (game.hasoutcome(pronostic.getgameoutcome())) { if (game.hasscore(pronostic.getscore())) { scoreearnings = FootballEarnings.SCORE; } else { scoreearnings = 0; } } } result.increaseamount("score", scoreearnings); if (pronostic.hasstrikers()) { result.updatestrikersearnings(pronostic, game.getresult()); } } return result;} Algorithme de calcul des points pour un match 41

42 @Test public void computeearningsforgame1maxscore() { FootballBetPronostic pronostic = FootballBetPronostic.forGame(gameOfTheDay1()); int expectedamount = 0; String explanation = "Webdev 2 1 Studio (56' Damien, 87' Olivier, 88' Fred)"; pronostic.setgameoutcome(footballgameoutcome.home_victory); expectedamount += FootballEarnings.GAMEOFTHEDAY_GAME_OUTCOME + FootballEarnings.FAVORITE_TEAM_BONUS; explanation += " : résultat +" + FootballEarnings.GAMEOFTHEDAY_GAME_OUTCOME; explanation += " bonus équipe favorite +" + FootballEarnings.FAVORITE_TEAM_BONUS; pronostic.setscore(new FootballScore(2, 1)); expectedamount += FootballEarnings.SCORE; explanation += " score +" + FootballEarnings.SCORE; pronostic.withhomestrikers(damien, olivier); pronostic.withawaystrikers(fred); expectedamount += 3 * FootballEarnings.STRIKER; explanation += " buteurs +" + 3 * FootballEarnings.STRIKER; FootballBetEarnings result = FootballEarningsComputer.computeEarnings(pronostic, gameoftheday1(), "webdev"); } assertthat(result.getamount()).isequalto(expectedamount); assertthat(result.getgoodpronosticcount()).isequalto(1); assertthat(result.getguessedstrikercount()).isequalto(3); assertthat(result.getgoodpronosticcountforfavoriteteam()).isequalto(1); assertthat(result.getexplanation()).isequalto(explanation); Un test unitaire associé à l algorithme Le processus total de classement des joueurs à l issue d une journée de championnat est le suivant : - une phase de calcul des points, de complexité linéaire par rapport au nombre de joueurs qui ont participé dans l objet Pari - une première phase de mise à jour des objets Classement des participants avec les points gagnés, de complexité linéaire également. - les participants sont classés. Pour le classement, on utilise directement la base MongoDB avec une clause order. Avec un index sur les colonnes pertinentes ce processus est également linéaire. Passer par la base nous assure de la scalabilité de notre algorithme de tri : lorsqu on trie une liste dans le code Java tous les objets sont montés en mémoire. - deuxième phase de mise à jour des objets Classement, car certains points bonus dépendent du rang de classement des joueurs - les participants sont reclassés pour prendre en compte les points bonus éventuellement attribués Ce processus est donc potentiellement long selon le nombre de participants, c est pourquoi il a été prévu sur le site des mécaniques d affichage pour signaler aux usagers que le calcul est en cours. 42

43 4.4 Prototype Pour ce projet, un prototype a été réalisé rapidement afin de mettre en place et de tester les mécaniques du jeu. En l absence des composants graphiques du studio, le prototype a été réalisé avec Bootstrap ( une sorte de librairie CSS libre réalisée par l équipe de Twitter, permettant d obtenir un graphisme élégant, sans effort. Cet outil est particulièrement utile pour le développement de prototypes ou d interfaces administrateur. Formulaire de pari réalisé avec Bootstrap Page de classement réalisée avec Bootstrap 43

44 Design final du site 4.5 Conclusion Le lancement officiel du produit a eu lieu le jour du premier match de la saison de Ligue 1, le 9 août En septembre, le jeu enregistrait une moyenne de 1200 paris par journée de championnat pour une fréquentation quotidienne moyenne de 800 visiteurs uniques. 44

45 Métriques Google Analytics depuis le lancement du site jusqu au 7 septembre On observe sur le graphique que le site enregistre un pic de fréquentation tous les vendredis, ce qui correspond au premier match de chaque journée de championnat. En effet, des mails de relance sont envoyés à toutes les personnes ayant déjà joué au moins une fois mais n ayant pas encore parié sur la journée en cours, le vendredi avant le premier match. Ces mails ont un impact important, ce qui montre que les gens qui ont joué sont plutôt enclins à revenir. Cette tendance est aussi visible lorsque l on s intéresse à la proportion de nouveaux visiteurs par rapport aux visiteurs qui reviennent (45/55 %). Cependant le bilan actuel du projet est malgré tout mitigé, les objectifs de fréquentation d un tel produit étant plutôt fixés sur une base de paris par journée de championnat. 5. Refonte du CMS interne Revo Nom : revo.rtl.fr Besoin : Refonte du gestionnaire de contenu, pour obtenir une application plus ergonomique, plus agréable à utiliser et avec un code plus facilement maintenable Etat actuel : en cours Technologies utilisées : Java, Spring MVC, MongoDB GWT, Bootstrap 5.1 Contexte Le gestionnaire de contenus des sites RTLNet a été entièrement développé en interne pour répondre à 45

46 des problématiques précises pour chaque marque utilisatrice. Il a été lancé il y a 5 ans, et modifié continuellement depuis. Au fil des années et des demandes, celui-ci s est enrichi de nombreuses fonctionnalités dont certaines ne sont plus utilisées et polluent l expérience utilisateur. Typiquement, lorsqu il crée un article, un journaliste doit actuellement uploader 6 formats différents pour une même image, et les interfaces sont remplies de boutons et de champs de recherches dont il est parfois difficile de déceler le sens. Le but du projet de refonte était donc d épurer l interface en se posant la question de l utilité et de l usage de chaque fonctionnalité lors de la migration de chaque module. Une reflexion sur l interface utilisateur a également été menée en essayant de créer des composants graphiques facilitant la vie des usagers. L occasion a également été saisie de passer à un graphisme Bootstrap, ce qui a réduit le coût de développement d une charte graphique à quasiment 0, tout en présentant un design moderne et sympathique. 5.2 Outil utilisé : GWT Google Web Toolkit (GWT) La première version de Revo a été réalisée avec GWT, une suite d outils développée par Google permettant de compiler du code écrit en Java en Javascript. Ainsi, il est possible d obtenir une interface client dynamique en Javascript en profitant des facilités du langage Java pour le développement et la maintenance du code. Pour la refonte, le framework Dart ( a été envisagé, mais n a pas été jugé assez mature, le nouveau projet se base donc également sur GWT, bien que son développement ait été mis de côté par Google. Néanmoins, la refonte a été l occasion d utiliser la dernière version de GWT qui apporte de nouvelles fonctionnalités intéressantes, notamment l UIBinder. L UIBinder permet de créer des interfaces graphiques avec une structure très proche de l HTML, ce que ne permettaient pas les premières versions de GWT. Avant, il était nécessaire d instancier une classe Java pour chaque composant graphique, à la manière de la suite d outils graphiques Java Swing. Maintenant, il est possible de décrire totalement un module dans un fichier pseudo-html. <!DOCTYPE ui:uibinder SYSTEM " <ui:uibinder xmlns:ui='urn:ui:com.google.gwt.uibinder' xmlns:g="urn:import:com.google.gwt.user.client.ui" xmlns:revo='urn:import:fr.rtl.revo.commons.client.ui' xmlns:field='urn:import:fr.rtl.revo.commons.client.ui.field'> <ui:style>.controls { padding top: 5px; 46

47 } </ui:style> <g:htmlpanel> <form class="form horizontal" onsubmit="return false;"> <g:htmlpanel ui:field="idpanel" stylename="form group"> <label class="col lg 3 control label">id</label> <div class="col lg 9 {style.controls}"> <revo:objectidlabel ui:field="id"/> </div> </g:htmlpanel> <div class="form group"> <label class="col lg 3 control label">name</label> <g:htmlpanel stylename="col lg 6" > <field:textfield ui:field="name" maxlength="255" /> </g:htmlpanel> </div> <g:htmlpanel> Extrait d UIBinder public class SecurityGroupsEditor extends Composite implements EntityEditor<GwtRevoGroup> { interface MyUiBinder extends UiBinder<HTMLPanel, SecurityGroupsEditor> { } private static MyUiBinder uibinder = GWT.create(MyUiBinder.class); interface Driver extends SimpleBeanEditorDriver<GwtRevoGroup, SecurityGroupsEditor> { } private final HTMLPanel ObjectIdLabel TextField name; public SecurityGroupsEditor() { initwidget(uibinder.createandbindui(this)); driver = GWT.create(Driver.class); driver.initialize(this); name.setrequired(true); RevoGroupRevoServiceAsync service = GWT.create(RevoGroupRevoService.class); } } Classe Java associée Les champs ui:field= permettent de référencer l élément dans le code Java avec une Il existe une librairie native de composants basiques comme les <div>, les <button>, etc Il est également possible 47

48 de créer ses propres composants et de les réutiliser dans les UIBinder. C est le cas du composant <field:textfield> dans l exemple, il s agit d un champ texte customisé pour enforcer une longueur maximale. Cette approche permet de se concentrer sur la partie fonctionnelle dans le code, et donc de réduire de manière conséquente celui-ci. 5.3 Programmation Orientée Aspect 7 Nous avons utilisé la Programmation Orientée Aspect (AOP) pour résoudre des problématiques telles que la nécessité de garder une trace de tous les appels aux bases de données. Cela permet ainsi de retrouver les appels qui ont posé problème dans le cas de bug par exemple. Les aspects sont alors appelés grâce à la définition de points d insertion dans le code. L idée est de définir un système d expressions rationnelles pour les points d insertion, de manière à ne pas devoir tous les insérer manuellement dans public class LogAspect && target(service)") public void method(joinpoint joinpoint, RemoteService service) throws Throwable { log(joinpoint, service); } } public void log(joinpoint joinpoint, RemoteService service) throws Throwable { // save logs } Dans ce cas, l aspect de log est exécuté avant les méthodes de toutes les classes - contenant le mot Service dans leur nom - situées dans un package server de Revo - qui implémentent l interface RemoteService Cet aspect résout une problématique générale à toute l application mais il est également possible d écrire des aspects sous forme d annotations à appliquer ponctuellement sur une méthode. C est la stratégie qui a été choisie pour la sécurisation des appels à la base. Chaque action demandant des permissions particulières, l aspect de sécurité est appliqué à la main lors du développement de = "netia") public class NetiaExportedSoundRevoServiceImpl implements NetiaExportedSoundRevoService { Exemple d utilisation de l aspect Security 5.4 Flat design L utilisation de Bootstrap a grandement contribué à la clarification de l interface. Nous avons utilisé 7 Paradigme de programmation qui permet de traiter séparément les préoccupations transverses qui relèvent souvent de la technique des préoccupations métier constituant le coeur de l application ( 48

49 Bootstrap 3, qui implémente un flat design, c est-à-dire sans effet de relief sur les composants. Bootstrap 3 fournit également des outils pour obtenir un site responsive, dont l interface s adapte à la taille de l écran de l utilisateur. Cette fonctionnalité est très importante car les utilisateurs de Revo souhaitent pouvoir s en servir sur tablettes et téléphones. Si le site se dégrade de manière très acceptable sur tablette, certaines interfaces restent malgré tout trop riches pour offrir une expérience utilisateur satisfaisante sur le petit écran d un téléphone portable. Page d accueil de l ancienne version Page de modules de la nouvelle version 49

50 Tous les formulaires ont été revus afin de les rendre plus lisibles, un seul champ de recherche a par exemple été laissé en haut de la liste des objets d un module, les champs de recherche avancée ont été isolés dans une pop-up. Pop-up de recherche avancée 5.5 Fonctionnalités HTML 5 Il est possible dans GWT de créer directement des fonctions en Javascript avec le mot-clé native. Cela permet de tirer partie des API Javascript, comme par exemple la File API qui permet de gérer les évènements de drag&drop en HTML 5. Cela nous a permis de créer un module d upload de fichiers images en glisser/déposer qui a été très bien accueilli par les utilisateurs. private native JavaScriptObject newformdata(string domain, JsArrayString tags, String maxwidth, String maxheight)/* { var formdata = new FormData(); formdata.append('domain', domain); formdata.append('tags', tags); formdata.append('maxwidth', maxwidth); formdata.append('maxheight', maxheight); return formdata; } */; Fonction Javascript incluse dans une classe Java 5.6 Conclusion Le CMS Revo compte actuellement plus de 350 comptes utilisateurs, avec des disparités dans les fréquences d utilisation. L application enregistre plusieurs dizaines de connexions par jour. La refonte se fait en collaboration avec les utilisateurs, qui ont assisté à une présentation du projet et ont été invité à communiquer leurs besoins et les éventuels problèmes avec la nouvelle interface. 50