Breizhcamp 2016 – Compte-rendu de la journée du vendredi

Dernier jour du Breizhcamp ! Et encore une belle journée. Et je vous ai sélectionné trois talks que je vais vous résumer ici.

Le réseau, cet inconnu au coeur de vos applications – par Raphaël Luta

C’est l’un des sujets qui m’a le plus surpris. A vrai dire, en tant que développeur, on pense souvent que le réseau n’est pas notre affaire. Et pourtant… voici ce que nous a appris Raphaël.

Si parfois il arrive que l’on soit très fier de l’application que l’on a développé (enfin, pour les vaniteux comme moi du moins, ce n’est pour autant pas forcément le cas du client, notamment côté performance. Malgré notre attention portée à toutes les optimisations (bon d’accord, « toutes » c’est un grand mot, mais quand même), on se retrouve souvent en production avec une impression de déjà-vu venant tout droit venue des années 1990 sous Windows 3.1 ?

Tout d’abord, lorsque l’on parle de réseau, on change de point de vue. Dans une application, on voit les requêtes comme si elles ne faisaient qu’une. Côté réseau, les seules choses qui comptent, ce sont les paquets, et la manière dont ils transitent.

Alors, quels sont les critères déterminants pour le voyage de nos chers paquets ? Laissez-moi deviner, vous pensez à la bande passante ? Oui, la bande passante joue un rôle déterminant, mais à elle-seule la bande passante n’est rien. Notre orateur cite, lui, les suivants :

• la bande passante
• la latence
• le taux d’erreur
• le duplex
• le MTU (Maximum Transmission Unit)
• le Jitter (ou Gigue, en français)

Il y a également une autre mesure intéressante qui s’appelle le BDP (Bandwidth-Delay Product) qui équivaut à la bande passante multipliée par la latence.

Pour comprendre le rôle de chacune de ces grandeurs, et puisqu’il s’agit bien de circulation (de paquets), on peut facilement faire la comparaison avec une route pour véhicules motorisés de façon à mieux se les représenter. La bande passante représente le nombre de voies parallèles sur lesquelles les voitures vont dans un même sens, la latence la limitation de vitesse, le MTU la taille de chaque voie, le full duplex la circulation à deux sens, le half duplex la circulation alternée, le jitter les zebras, et le taux d’erreur les accidents de la route.

Cela fait déjà un bon nombre de paramètres n’est-ce pas ? On comprend aisément que les conditions idéales sont une bande passante très large, une latence très faible, un taux d’erreur très faible, un gros MTU et du full duplex. On comprend  aussi que si une bande passante peut accélérer de manière importante le téléchargement d’un gros fichier, elle n’est en revanche d’aucune utilité pour la vitesse d’une succession de nombreuses requêtes/réponses. Alors pourquoi ne parle-t-on quasiment que de la bande passante ? L’augmentation de la bande passante ces dernières décennies a suivi la loi de Moore. On peut l’améliorer, et la marketer sans trop de risque, car on sait qu’elle peut toujours être augmentée. En revanche, la latence a des limitations physiques. On pourra faire les améliorations que l’on veut, jamais personne n’arrivera a dépasser la vitesse de la lumière. Ceci étant dit, certaines conditions diminuent de manière significative la latence comme par exemple la fibre optique, qui, à bandes passantes égales, feront du réseau optique un réseau beaucoup plus performant qu’un réseau par câble.

Après une comparaison du TCP avec l’UDP, et nous avoir fait une simulation graphique assez bluffante de l’effet des variations des différents paramètres, notre speaker nous met en garde contre le gaspillage de place.

Imaginez que vous envoyiez une clé USB dans un carton énorme ?! Retirons les espaces blancs, les commentaires, réduisons les noms trop longs dans tout ce qui part sur le réseau ! On peut aussi jouer sur les protocoles plutôt que d’envoyer du format texte (protobuf, thrift, avro, …), compresser (avec Snappy par exemple, qui offre un bon compromis entre rapidité de sérialisation et compression). Les bases de données souffrent souvent, elles aussi, de négligence dans la manière dont elles sont requêtées.

Nous terminerons donc en essayant d’oublier la fausse idée que la bande passante est la solution à tous nos problèmes. Et surtout, rappelons-nous que notre manière de développer et de benchmarker peut faire toute la différence dans l’utilisation du réseau.

Kill all the REST with the Falcor – par Hugo Wood

Ce talk a beaucoup attisé ma curiosité et mon intérêt. Si vous aussi vous êtes fatigués de coupler le code des ressources à l’usage des clients, cette technologie est pour vous.

En effet, parfois, on se retrouve à faire le choix entre remonter une arborescence gigantesque sur le réseau par une API REST ou devoir écrire des routes « à la pelle » pour se conformer à chacun des usages des ressources.

Falcor répond à ce problème en préférant une route unique, servant à la fois pour les queries ou les updates, et permettant de ne remonter que les parties du graphe d’objets dont nous avons besoin. En plus d’optimiser le trafic réseau, Falcor est facile d’utilisation puisqu’une requête ressemble comme 2 gouttes d’eau au parcours d’un objet en Javascript (ex: http://server/resource?todos[0].name), mais il est également possible de requêter un range (ex: todos[0..9].name) ou encore plusieurs ids précis à la fois ne nécessitant qu’un seul appel, et même de lancer des requêtes en batch. Avec en prime un système de cache.

Cela m’a vraiment donné envie de l’utiliser !

DevOps sur Android : D’un git push à une release sur le Play Store – par Jérémie Martinez

Jérémie, arrivé il y a quelques mois chez Captain Train, a mené un bon nombre travaux pour aller vers le Continuous Delivery de l’application Android. Si vous n’avez pas la chance d’aller le voir à Devoxx, voici un aperçu des expériences qu’il en a tirées et qu’il a décidé de partager avec nous.

Le premier niveau, l’intégration continue, tient à plusieurs choses. Il faut d’abord se munir d’un bon gestionnaire de dépendances. Dans le monde Android, celui qui s’impose est Gradle. Il faut ensuite prendre soin de ses tests automatisés. Les tests automatisés sur Android pâtissent de la réputation d’être trop compliqué à mettre en place. Jérémie n’est cependant pas d’accord.

Premièrement, si les tests utilisant des appareils physiques peuvent compliquer la tâche, n’oublions pas les tests unitaires! Sur Android, il est très simple d’utiliser JUnit 4. Et si l’on a besoin de mocker les interactions avec l’appareil, Robolectric est là pour vous sauver la mise. Il s’agit aussi de tester les bonnes choses. Tester Android est inutile. Tester la bonne utilisation d’Android, en revanche, est bénéfique. Pour les tests d’intégration, on pourra utiliser Espresso, mais en gardant en tête seulement le user flow principal, comme rechercher un billet de train, mettre en panier, payer ou récupérer ses billets.

Nous nous sommes ainsi déjà assuré de ne pas faire de grosse bêtise. Mais qu’en est-il de la bonne structure du code ? Jérémie, lui, utilise SonarQube et pratique beaucoup la code review avec ses collègues. Il utilise également Lint et nous en fait des louanges car très personnalisable, simple à mettre en place et intégré par l’IDE. Pour terminer son intégration continue, il ne reste plus qu’à automatiser les différentes opérations de packaging en prenant garde de filtrer les ressources, et de bien signer l’APK.

Une fois passé l’intégration continue, il est temps de livrer, n’est-ce pas ? Jérémie et son équipe ont pris le parti d’adopter un modèle de release train de 6 semaines, plutôt que de déployer en continu. Cela pour s’assurer un nombre suffisant de contenu et ainsi mieux faire valoir les améliorations auprès des utilisateurs. Le process de release qui nous est décrit est vraiment poussé niveau automatisation, allant jusqu’à automatiser les screenshots, vérifier que les permissions demandées sur le store n’excède pas celles requises par le fonctionnel de l’application et utiliser l’API du playstore pour pousser le précieux artefact.

A travers cette présentation, Jérémie a démontré que le monde de la mobilité comprend des développeurs réellement impliqués dans la qualité de ce qu’ils produisent. C’est très plaisant !

Fin du BreizhCamp

C’était le dernier résumé du Breizhcamp sur notre blog. Je remercie sincèrement les organisateurs et les speakers qui ont sacrément assuré. Personnellement, c’était mon premier Breizhcamp et une chose est sûre, je serai présent l’an prochain. J’espère que notre retour vous a aussi donné envie d’y aller ! On s’y retrouve l’an prochain ?

Si vous avez raté nos deux premiers résumés, vous pouvez toujours consulter le résumé du premier de jour de Breizhcamp et aussi la journée de jeudi.