Devoxx France – Retour sur le jour 3

Du 20 au 22 avril au Palais des Congrès, c’était la 5^e édition de Devoxx France, la conférence des développeurs passionnés !

Nous ne pouvions pas manquer ce rendez-vous incontournable. Une trentaine de Xebians étaient présents. Voici les retours sur leurs conférences « Coup de cœur ». 

Découvrez leurs retours sur la journée 1 et 2 de Devoxx France.

Keynotes

Par Louis LAROCHE

De l’utopie de la fin du travail au digital labour – Sébastien Broca

Selon Sébastien Broca, l’image qui est dépeinte de notre société (médias, politique) est une dystopie, ou contre-utopie. Le tableau, s’il n’est pas complètement noir aujourd’hui, serait en passe de le devenir demain. Nous craignons que les bonds de productivité que nous faisons grâce à l’avancée technologique impacte l’emploi à moyen terme de manière significative. Sébastien s’appuie sur un article à peine alarmiste du MIT.  

Cette crainte n’est pas nouvelle : toutes les époques ont eu cette peur, nous raconte-t-il. Depuis la première machine à tisser, puis évidemment de manière plus importante à l’ère industrielle. Bien qu’à chaque époque, on ait assisté à une mutation du travail, il n’a évidemment pas disparu, loin de là.

La fin du travail pourrait-elle être une fin en soi ? En effet, dans la logique de l’utopie, le travail tel que nous le connaissons n’est pas un objectif. Si l’on part des écrits de Thomas More, les Utopiens travaillent 6 h par jour, voire moins les jours où l’activité ne le nécessite pas. Le reste du temps, ils effectuent des activités de loisir, à ne pas confondre avec oisiveté. On parle ici de créer du lien social, de culture, de sport, de divertissement. Dans le phalanstère de Charles Fourier, chacun accompli jusqu’à 8 activités par jour, toutes choisies selon les goûts des travailleurs. Et c’est parce que tous les membres de la société veulent montrer leur valeur à leurs pairs que l’ensemble tourne rond.

Quels liens entre travail et progrès technique ? D’une part, les machines peuvent réduire la quantité de travail nécessaire (et c’est souvent face à ce nouveau paradigme que nous peinons à nous renouveler). D’autre part, les machines peuvent aussi améliorer la qualité de la production. Certaines tâches sont d’ailleurs bien mieux, dans les 2 sens, effectuées par des machines que par des humains (pensez à la dernière fois que vous avez plus fait confiance à vos capacités de calcul mental plutôt qu’à votre calculette ou feuille de calcul).

Notre rapport au travail évolue. Sébastien prend en exemple les développeurs qui n’accompliraient plus leur travail par devoir moral ou par nécessité financière. Il est accompli par passion, par intérêt personnel, il est vecteur de la réalisation de soi. Notons que si les développeurs peuvent avoir cette approche c’est certainement dû au fait que leurs besoins plus basiques sont déjà satisfaits.

Qui sont les acteurs du numérique ? Sébastien divise ces acteurs en 3 catégories, les illustrant par des exemples :

• Les salariés : les codeurs de Google qui semblent travailler par intérêt technique, ont une forme d’emploi pérenne et une rémunération très confortable. À l’autre bout du spectre, n’oublions pas les chauffeurs d’Uber qui eux aimeraient bien devenir salariés, quitte à mener des actions de justice.

• Les indépendants : ce qui caractérise les codeurs indépendants c’est la liberté de s’organiser, et des activités très diverses. En revanche, les indépendants d’Amazon Mechanical Turk sont payés au lance pierre, et cumulent plusieurs activités pour avoir un salaire correct. Enfin, les livreurs à vélo – qui se multiplient depuis peu – sont aussi indépendants, payés à la course ou au forfait et propriétaire de leur véhicule de travail.

• Les internautes : si si, nous participons à la création de valeur sans nous en apercevoir. Un clic, une recherche, la création d’un logiciel libre, le commentaire de vidéo, etc. Tout ceci crée de la valeur, parfois accessible (open source) mais la plupart du temps la valeur est captée par les grands acteurs du numérique.

Sébastien tranche, nous n’assistons certainement pas à la fin du travail mais à une de ses nombreuses mutations. Certes, la réalité moins réjouissante que la vision utopique, que l’on peut parfois entendre être qualifiée de déconnectée de la réalité. Sébastien propose, plutôt que de moquer les utopistes, de se servir de l’utopie comme boussole.

Algorithmes, les nouveaux pouvoir du développeur – Fabrice Epelboin

WTF are devs ? C’est l’intro du slot de Fabrice Epelboin, bien qu’à Devoxx tout le monde soit évidemment bien à jour sur le sujet, d’autres se posent encore la question. Et c’est peut être là le cœur du problème du monde politique. Fabrice nous décrit une chaîne de l’information, jusqu’à la prise d’action, de l’informatique à la politique en somme. Voici l’intégralité de la chaîne : (Informatique) s’informer → connaître → ressentir → prédire → agir (politique). Si tout se passait bien du coup, les actions politiques se baseraient sur la connaissance la plus complète possible de l’information. Selon Fabrice, la machine politique bloque à « connaître », le 2^e stade donc, ouch.

Code rules. Sûrement en grande partie à cause de ce dysfonctionnement, l’informatique a pris le pas sur le politique : c’est le code qui fait la loi. Il façonne nos sociétés depuis des décennies. Si l’on reprend la devise de la république française, le code a bien plus fait bouger les lignes des 3 fondements que la loi :

• Liberté : d’expression avec les réseaux sociaux (Facebook, Twitter). C’est une liberté d’expression à l’américaine (façon premier amendement) qui est appliquée au monde entier (ex. : printemps arabes).

• Égalité : l’accès à l’information au sens large est plus égalitaire que jamais (Google news, journaux en ligne) et sa diffusion aussi (WordPress). Concernant la culture, qu’elle soit générale (Wikipedia vs. les bibliothèques), ou musicale (napster, la démocratisation du P2P, l’iPod, Spotify).

• Fraternité :  l’open-source domine le monde du développement logiciel, les langages les plus populaires le sont.

L’effondrement de la confiance. D’après l’observatoire de Science Po, que Fabrice représente, il y a assez peu et de moins en moins de confiance entre les différents acteurs du monde économique. Il nous montre notamment quelques taux de confiance compris entre 20 et 50% (grand maximum) des français envers de grandes institutions (entreprises du CAC, banques, médias, politiques.). De la même manière qu’elle s’est effondrée pour les institutions traditionnelles, la confiance est en passe de s’effondrer également pour le numérique. Les révélations de Snowden, soit l’évènement ayant le plus impacté la confiance envers le numérique, représenteraient une perte nette de 180 milliards de dollars pour l’économie numérique, selon Forrester. Si la confiance venait encore à diminuer entre les acteurs, ce pourrait être catastrophique pour l’économie numérique.

On conclut par des solutions, ouf. Tout d’abord, pour rétablir la confiance, on pourrait s’attaquer à la transparence du code. Bonne nouvelle, on a une réponse toute faite à cela, l’open source. Deuxième souci identifié par le speaker : la sécurité, trop rarement dans les préoccupations principales des codeurs. Là encore, inspirons-nous de l’existant, le mouvement DevOps nous a prouvé que l’on pouvait rapprocher deux mondes que tout opposait. Créons le DevOpsSec !

Nos favoris

Le design d’API REST, un débat sans fin ? – Guillaume Laforge

Par Arthur Sudre

Guillaume Laforge nous a présenté toutes les bonnes pratiques concernant les API REST. Un bon aperçu de toutes les questions que l’on est amené à se poser :

Commençons par le nommage des URL : il est d’usage de choisir des noms plutôt que des verbes pour les routes, d’utiliser le pluriel, par exemple : GET /api/users/123. Il peut y avoir des exceptions malgré tout, entre autres : /login, /logout. Concernant la casse, même si Guillaume est favorable au lowercase ou au snake_case, il nous a expliqué que l’important, surtout, était d’être constant dans le choix que l’on a fait sur son projet.

Les relations sont décrites dans les urls comme le chemin d’un arbre, en définissant le type, puis l’identifiant. Prenons l’exemple : GET /tickets/123/messages/4, parmi les tickets, on sélectionne celui d’identifiant 123, pour lequel on souhaite récupérer le message d’identifiant 4.

Où mettre ces paramètres, cela va dépendre de son usage, on retrouve dans :

• le path, les variables nécessaires : GET /users/id
• le query, les variable pour « affiner » le résultat (recherche, tri, etc.) : GET /users?surname=Didier
• le body, les données : présentent en POST/PUT pour insérer ou mettre à jour
• le headers, ce sont des variables globales (API keys, etc.)

Guillaume nous a présenté une structure amusante des codes de statuts :

• 1XX : Hold on
• 2XX : Here we go
• 3XX : Go away
• 4XX : You fucked up!
• 5XX : I fucked up!

Toujours sur les statuts, il faut penser à utiliser d’autres statuts que les 200 (OK) et 201 (created) et offrir à l’utilisateur plus de précision sur le traitement. Par exemple, les codes 202 (traitement asynchrone), 204 (pas de contenu), 206 (contenu partiel (pagination)), 304 (non modifié). Vous pouvez trouver tous les codes sur ces pages humoristiques : https://http.cat/, https://httpstatusdogs.com/.
Il peut être intéressant de rajouter des informations dans les headers, par exemple : location pour un retour 201, ou modified-since/last-modified pour une 304, …

Le sujet abordé ensuite était celui de la pagination. Les paramètres sont envoyés dans des « query strings », on peut utiliser différentes méthodes :

• numéro de page : ?page=1, qui peut aussi spécifier une taille de page. On peut avoir des effets non maîtrisés s’il y a une insertion pendant l’affichage des résultats.
• curseur : ?cursor=2a47e2, fonctionne bien s’il y a des insertions.
• sémantique : ?page=A : utile quand le nombre de résultats est limité.

On peut avoir une variable en header pour la pagination : Accept-Ranges: users, Content-Ranges: users 0-9/200, pour les utilisateurs de 0 à 9 sur 200 existants.

Dans le cas de où vous retournez des collections, il est préférable de renvoyer directement celles-ci, un simple tableau en JSON, si aucune autre donnée n’est attendue ([…]) et de ne pas la « wrapper ».

Si le client reçoit des statuts qui n’existent pas, il doit les considérer comme les statuts génériques de la famille :

• 4XX : 400 : erreur cliente générique
• 5XX : 500 : erreur serveur générique

Il est possible d’envoyer des informations au client sur les contraintes de débit du serveur avec les paramètres suivants :

• X-RateLimit-Limit: 60 : nombre total de requêtes autorisées.
• X-RateLimit-Remaining: 56 : nombre de requêtes restantes.
• X-RateLimit-Reset: 14538745703 : date à laquelle la limite sera réinitialisée.

 Le filtrage est utilisé avec des « query strings » :

• champs : ?fields=firstname,age
• exclusions : ?exclude=surname
• style : ?style=compact

Mais on peut également avoir les headers pour définir le style : Prefer: return=minimal
Pour la recherche, le même principe est appliqué : ?name=Laforge&firstname=guillaume.
Même chose pour le tri : ?sort=title+DESC, ?sort=title+DESC,author+ASC, etc.
Pour tous ces sujets, d’autres technologies existent : GraphQL de Facebook et Falcor de Netflix qui est présenté dans cet article également.

Le versioning est généralement utilisé dans le chemin de l’url : http://api.fr/api/v1/users, mais on le retrouve parfois dans le header : X-API-Version: 2

Guillaume nous a parlé d’hypermedia, en faisant une introduction sur le modèle de maturité de Richardson, dont vous pouvez trouver un article intéressant à ce lien : Richardson’s maturity model. Il a ensuite expliqué les pour et contre de l’hypermedia :

• Pour : 
  • peut être utilisé de manière générique pour différents clients,
  • peut palier au besoin de versions.
• Contre : 
  • verbeux (et lourd), implique un problème d’usage pour les applications mobiles,
  • besoin que le client comprenne les liens et ce qu’ils représentent dans leur API.

Un bon slot pour partir sur de bonnes bases lors de la mise en place d’une API REST et avoir les bons réflexes qui faciliteront l’usage.

Kill all the REST with the Falcor – Hugo Wood

Par Alexis Kinsella

Après la session de Guillaume Laforge sur les bonnes pratiques REST, une session sur Falcor présentée par Hugo Wood de Zenika tombait à point. REST a maintenant une quinzaine d’années d’existence même si son usage s’est réellement démocratisé depuis une dizaine d’années tout au plus. Dans le monde du développement informatique, 10 années représentent tout de même une relativement longue période. Suffisamment longue pour se permettre de mesurer tous les bienfaits apportés par les architectures REST, tout comme les limites.

Des limites, auxquelles tentent de répondre Falcor proposé par Netflix, mais également Facebook avec GraphQL. Falcor a pour objectif de permettre au client de décider de quelles données il a besoin plutôt que le serveur ne se limite à proposer des API figées qui correspondent plus où moins au besoin de tel ou tel client.

Netflix dispose en effet d’un grand nombre de clients, et chacun d’eux dispose de spécificités. Il est bien entendu qu’un backend optimisé pour chacun des clients n’est pas imaginable, il est donc nécessaire de trouver une réponse au niveau de la souplesse des API pour s’adapter aux besoins des différents clients.

Ces besoins sont les suivants :

• Etre en mesure de ne demander que le contenu nécessaire lors de rendu des pages ou des traitements effectués.
• Limiter le nombre d’appels au serveur.
• Ne pas recharger des données qui ont déjà été accédées au préalable.

Le deux premiers points sont particulièrement intéressants pour les besoins mobiles car ils répondent aux objectifs de limiter aussi bien la bande passante que les temps de réponse. L’objectif premier de Falcor est de concilier couplage faible et performance, il valorise l’idée de simplicité et d’efficacité d’accès aux données. Pour répondre à ces besoins, Netflix a imaginé l’architecture proposée par Falcor, et la développé depuis 2011.

Falcor s’appuie sur JSON pour les structures de données échangées, et HTTP pour le transport. Néanmoins, les données échangées par le client et le serveur se font via un point d’échange unique. Pour fonctionner, Falcor a besoin d’une librairie côté client et d’une librairie côté serveur. Ce sont ces librairies qui s’occupent de réaliser le gros du travail. On ne travaille plus directement avec la couche HTTP, c’est la librairie qui s’en charge.

Contrairement aux API REST qui prédéfinissent les données échangées côté serveur, ici, le pouvoir est redonné au client qui a la possibilité de définir via une expression simple quelles sont les données qui l’intéressent. Charge au serveur d’interpréter cette expression, et de construire la structure de données correspondante qui sera alors retournée au client.

Un point intéressant tient dans le fait que Falcor, tout comme GraphQL permettent non seulement au client d’exprimer au serveur les données qui l’intéressent, mais également de lui communiquer des instructions de mutation des données. Charge sera donnée au serveur d’appliquer correctement ces mutations. En tout et pour tout, il sera nécessaire au serveur d’implémenter 3 fonctions : get, set & call.

Ces évolutions proposées par ces architectures de nouvelle génération peuvent sembler brutales par rapport aux efforts de normalisation proposés depuis plusieurs années autour des API REST, mais il semble inévitable de devoir mettre un coup de pied dans la fourmilière pour trouver de nouvelles solutions qui répondent mieux aux besoins de la diversité des besoins d’accès aux données des applications actuelles.

En attendant d’avoir accès aux slides de la session Devoxx, il est possible d’en apprendre plus sur Falcor en découvrant un peu plus le sujet via les ressources suivantes :

• https://speakerdeck.com/btholt/falcorjs-and-react (Slides)
• https://github.com/Netflix/falcor (GitHub)
• https://twitter.com/falcorjs?lang=fr (Twitter)
• https://wiredcraft.com/blog/falcor-dataflow/ (Article)
• http://netflix.github.io/falcor/starter/what-is-falcor.html (Documentation officielle)

Des technologies telles que Falcor ou GraphQL sont encore jeunes, et il n’est pas possible à l’heure actuelle de savoir si ces technologies vont à un moment ou un autre prendre le pas sur les architectures REST classiques. Néanmoins GraphQL semble attirer l’attention et remporte une certaine adhésion, bien que considéré à l’heure actuelle comme étant plus fastidieux à implémenter que Falcor.

Spring Cloud: Exploring Spring Cloud Implementations – Spencer Gibb

Par Fabian Gutierrez

Spencer Gibb de pivotal Inc, explique pourquoi la découverte des services est un des éléments les plus importants dans l’écosystème spring-cloud. L’objectif de base est de pouvoir consommer les différentes instances de nos services exposés dès qu’ils sont disponibles et d’être informé dès qu’ils s’arrêtent. Cependant, pour avoir accès à ces événements, il est impératif d’avoir une configuration qui soit capable de se mettre à jour automatiquement. Donc on parle des deux composants : un mécanisme de configuration et un autre de registry.

Concernant, le config server, on discute sur l’implementation officielle d’un config server: Spring Cloud Config Server et les origines possibles supportées pour notre conf (eg. fichier properties, variables d’environnement et même github). On assiste à quelques démos bluffantes dans lesquelles on consomme des paramètres de config depuis différentes origines et met à jour nos services en utilisant un bus d’évènements interne à spring-cloud.

Finalement Spencer nous explique sa vision sur trois implémentations d’un registry dans Spring cloud :

• Netflix Eureka, mature, hautement disponible et utilisé chez Netflix. Il est basé sur la JVM (ça dérange certain ops!) et pensé principalement pour AWS.
• Consul (écrit en go!), il est à la fois un serveur de config et registry qui a un DNS interne. Il a système de sécurité built-in (extensible avec vault), des health checks pour les services et supporte multiples datacenters.
• Zookeeper, c’est un store consistent, très mature et prouvé dans de nombreux projets Apache (eg. mesos), avec des API externes plutôt faciles à utiliser. Cependant, il a énormément des problèmes de scalabilité, de gestion complexe pour les environnements de prod (même si exhibitor aide pas mal).
• On discute brievement les nouveau arrivants :
  • Uber hyperbahN
  • Airbnb Smart Stack

DDD : Et si on reprenait l’histoire par le bon bout ? – Thomas Pierrain et Jérémie Grodziski

Par Ilja Kempf

Force est de constater que les concepts du Domain Driven Design ne sont pas particulièrement répandus dans le quotidien de développeurs et architectes. Le blue book, écrit par Eric Evans en 2003, était peut-être trop abstrait ou idéal pour être adopté/compris mais Thomas Pierrain et Jérémie Grodziski souhaiteraient que cela change en commençant par cette “réintroduction” au DDD.  Même s’il a été écrit dans un contexte fortement marqué par la programmation orienté objet, les principes de modélisations transcendent les modes et techniques et sont des guides précieux dans tout contexte de développement. 

Durant la conférence, Thomas et Jérémie nous présentent quelques principes du DDD qu’ils jugent essentiels et dont les apports sont dûment démontrés. Les principes présentés taclent les problèmes du cycle de développement d’une application à plusieurs niveaux. 

Premier niveau : le code

Toute application contient du code technique (sécurité, persistence, protocoles, etc.) mais l’objectif premier est de répondre à un besoin métier (Domain). Le code métier est l’implémentation d’un besoin/spécification et doit pouvoir se lire tel quel, la guideline à suivre tel que décrit dans le blue book : Make the implicit explicit. 

Pour y parvenir le DDD propose, entre autre, l’ubiquitous language et les value types. L’ubiquitous language est simplement l’utilisation d’un langage unique entre développeurs et métiers dans un contexte donné. Il faudra donc veiller à réutiliser le vocabulaire métier dans vos signatures de méthodes, noms de variables, constantes etc. L’utilisation de value types permettra de donner une sémantique métier à un/des type(s) primitif(s) (par exemple l’utilisation d’un type Amount plutôt qu’un flottant) en plus de définir les manipulations (d’un point de vue métier) possibles sur le type.

Deuxième niveau : l’application 

On veillera à ne pas mélanger le code du domaine avec du code technique. Cela peut ce faire au travers d’une architecture hexagonale par exemple. Le livre d’Eric Evans nous aide aussi à introduire progressivement les principes du DDD dans des applications legacy qui mélangent code métier et technique.

Troisième niveau : le système d’information

Il peut être le cas que notre application ait une ou des dépendances, on est donc en position de “downstream”. On aimerait protéger notre couche domaine des changements de ces dépendances.  Le ddd propose le anti-corruption layer pattern afin d’isoler la gestion des dépendances externes dans une couche technique de notre application. 

En conclusion, nous sommes encouragés à utiliser et/ou enrichir la boîte à outils qu’est le DDD dans l’objectif de créer une communauté vivante de praticiens autour de cette dernière.

Scalez de 0 à 10 millions d’utilisateurs avec AWS – Julien Simon

Par Gérôme Egron

Julien Simon est évangeliste AWS pour Amazon. Au cours de cette conférence, il nous a présenté différents services managés par AWS. On entend par managé que c’est la responsabilité d’Amazon de garantir la configuration, la scalabilité et la haute disponibilité d’un service.

Nous avons donc eu une présentation rapide des services suivants, qui je le rappelle, sont tous managés par Amazon :

• DynamoDB : base de données NoSQL
• Dynamo Stream : triggers sur les tables de dynamo
• Kinesis : commit log distribué, l’équivalent d’un kafka
• SQS : le plus vieux service d’AWS, Simple Queue Service
• Lambda : service de calcul sans serveur
• API Gateway

Après une étude de cas, Julien s’est attaqué à la partie la plus intéressante et la plus risquée de sa conférence : les démonstrations !
Dans un premier temps, il a déployé sur AWS les services permettant de monter un pipeline de données. Et ensuite dans un deuxième temps, il a déployé une application permettant au public d’interroger une URL afin de voir des photos de chats mais surtout de montrer la capacité d’une application à tourner sans aucun serveur dans AWS et de potentiellement scaler jusqu’à 10 millions d’utilisateurs.

Des LEDs pour remplacer votre routeur wifi ? – Alexis Duque

Par Qian Jin

Alexis Duque, doctorant et ingénieur chez Rtone, nous a parlé de la VLC (Visible light communication) suivi par une démonstration live qu’il a réalisé simplement avec un device Android et un LED.

Le terme Li-Fi (Light Fidelity) a été introduit par Professeur Harald Haas de l’Université d’Edimbourg lors d’une présentation TED en 2011. Haas envisage des ampoules qui pourraient agir en tant que routeurs sans fil. Au début de l’année 2015, les chercheurs de l’Université d’Oxford ont atteint la vitesses bidirectionnelles de 224 Gbps dans le lab. Ensuite dans l’année, plusieurs entreprises ont commencé des projets de pivot pour tester Li-Fi dans des environnements de bureaux et industriels. Derrière Li-Fi, c’est la communication de la lumière visible (VLC), un moyen de communication de données qui utilise la lumière visible entre 400 et 800 KHz (780-375 nm). VLC indique un sous-ensemble de technologies optiques de communication sans fil.

Le quickie commence par une introduction générale de la VLC avec quelque discussions sur son potentiel dans le domaine IoT :

• Comment décongestionner les réseaux et dé-saturer le spectre RF ?
• Comment optimiser la consommation énergétique/l’autonomie tout en étant connectés ?
• Comment réduire les coûts de production ?

On peut voir qu’il y a déjà pas mal d’usages de la VLC :

• les communications inter-objets ou humain à objet : comment l’éclairage déclenche des actions, un exemple particulièrement intéressant est le Magic Princess Dress développé par Disney, un coup de baguette magique avec une LED déclenche par magie des effets de lumière sur une robe de princesse.
• localisation indoor : la précision peut atteindre 10cm.

Last but not least, Alexis nous a fait une démo implémentée avec un device Android sous Lollipop et un LED verte. La démo utilise l’API caméra d’Android et le Rolling Shutter Effect pour simuler les signaux reçus depuis le movement de LED, afin de le localiser. Un petit teaser très sympa pour donner un sneak peek de l’avenir.

New Data Science : Functional, Distributed, JVM… and Agile – Andy Petrella

Par Sylvain Lequeux

Andy Petrella est à l’origine du Spark Notebook. À ce titre et au sein de son entreprise Data Fellas, il est amené à travailler avec des Data Scientists. Arrivé à un constat flagrant sur les gestions d’équipes Data, il souhaitait faire un retour un peu particulier ici à Devoxx. Il a tenté, lors de ce slot exclu de toute technique, d’évangéliser le public sur un point clé : la place des Data Scientists dans le SI de nos jours.

Retraçant d’où vient la Data Science, ce en quoi elle consiste et ses différences avec la Business Intelligence, il a présenté les points suivants :

• Les Data Scientists viennent souvent du monde de la recherche, ou encore des mathématiques, et ne sont pas, pour beaucoup en tout cas, à l’origine des informaticiens.
• Construire une équipe de Data Scientists et les placer seuls dans leur coin n’est pas la solution à adopter.
• L’idéal est l’inclusion de Data Scientists au sein d’équipes projet, à côté d’ingénieurs plus "classiques", et faire en sorte que toute l’équipe ait les mêmes objectifs et KPIs.
• L’objectif de tout cela est d’inclure le plus tôt possible le Data Scientist dans la "production line", afin que leur travail soit plus facilement et rapidement intégrable et industrialisable.

Cette solution est bénéfique à la fois pour le Data Scientist qui verra plus facilement son travail déployé en production, pour le reste des équipes qui pourra comprendre le Data Scientist et ne le verra plus comme une diva, mais également pour le projet qui progressera plus vite. Force est de constater que nous sommes en tous points d’accord sur ce sujet puisque nous avons également choisi cette solution au sein de notre Data Factory.

How to stop wasting your time and start performing useful code reviews – Maria Khalusova

Par Bastien Bonnet

Durant cette présentation efficace, Maria Khalusova a dressé de manière exhaustive le portrait d’une pratique de revue de code efficace. Dans cette optique, elle rappelle qu’il ne s’agit pas d’un remplacement d’autres techniques améliorant la qualité du code (tests automatisés, intégration continue, etc.), et que ce n’est pas non plus l’occasion de démarrer des conflits (espaces ou tabulations, quel est le meilleur framework, etc.).

Ont d’abord été rappelés les bénéfices de la pratique de la revue de code :

• détection d’anomalies,

• partage de la connaissance,

• facilitation de l’embarquement des nouveaux sur le projet,

• amélioration de la maintenabilité du code,

• augmentation du bus factor,

• amélioration de la collaboration.

L’oratrice rappelle que pour être bien acceptée et comprise de tous, la revue de code doit être pratiquée par toutes les personnes de l’équipe écrivant du code. Le reste de la présentation est un concentré de conseils, qui, même avec des années d’expériences dans la pratique de la revue de code, sont rarement appliqués dans leur intégralité.

Que regarder pendant la revue ?

Lors d’une revue de code, il faut considérer différents aspects :

• les erreurs :

• de codage

• d’exécutions : messages d’erreur

• dans l’implémentation des règles métier

• l’architecture :

• emplacement du nouveau code

• réutilisabilité

• structures de données

• application des principes SOLID

• application du principe YAGNI

• la lisibilité :

• nommage

• découpage

• documentation

• tests

• les performances

• la sécurité :

• bibliothèque tierce

• identification

• chiffrement des données

• gestions des mots de passe

En tant que personnne effectuant la revue

Dans ma pratique :

• je ne remets pas au lendemain

• je ne dois pas le subir comme une interruption des tâches habituelles ; par exemple, cela peut être effectué comme première tâche en arrivant le matin ou après le déjeuner

• je n’enchaine pas plus d’une heure de revue

• j’applique mon expertise

Dans mon comportement et mes manières :

• mon objectif est l’amélioration, pas la démonstration de ma supériorité

• je me concentre sur les changements du code, pas sur les personnes

• je choisis avec attention mon vocabulaire pour les retours :

• je suis poli

• je garde à l’esprit que l’auteur est une personne qualifiée

• je n’utilise pas de termes réducteurs tels que « évidemment » ou  « simplement »

• je ne formule rien de manière personnelle, par exemple plutôt que de dire ton code », je privilégie « cette méthode»

• je suis spécifique

• je ne formule pas d’exigences, mais plutôt des questions

• j’évite les sarcasmes, qui placeront l’auteur en position défensive

• je ne me contente pas de dire que ça ne va pas, je suggère des alternatives qui offrent un réel avantage

En tant qu’auteur du code review

Avant la revue :

• je documente pour faciliter la compréhension

• je mets des messages de commit utiles et descriptifs

Après la revue :

• je garde à l’esprit que le retour d’information, ou feedback, aide à s’améliorer

• je sépare la critique de mon travail de ma personne (ego)

• je pense à remercier quand cela m’a été utile et/ou m’a permis de progresser

From Angular 1 to Angular 2 – Benoit Lemoine

Par Paul-Guillaume Déjardin

Benoit Lemoine revient nous parler Front, Typescript et autres bizarreries du web pour nous exposer sa vision de comment passer son projet Angular 1 vers Angular 2. Il est vrai que c’est une question très répandue depuis début 2016, et il est difficile de trouver une réponse claire, voyons voir ce que le speaker nous propose.

Après un rapide rappel des dates historiques d’Angular 1 et Angular 2, on aboutit à un premier mini-tableau comparatif des différences majeures des deux versions, et pour ensuite montrer un exemple de composant Angular 2 :

• Angular 1 : Javascript, Orienté MV, Double databinding.
• Angular 2 : Typescript, Orienté Composant, databind presque unidirectionnel

Vient ensuite les étapes sur la migration progressive de Angular 1 vers Angular 2.

1. Suivre les bonnes pratiques :
   • Organiser son projet en module fonctionnel et pas technique (le guide de style de John Papa est idéal pour ca).
   • Utiliser “.service()” et éviter “.factory()”, en effet seul les services survivent dans la nouvelle version d’Angular.
   • Bannir “$scope” et utiliser controllerAs dans la configuration des routes
2. Les composants :

   • Si cela est possible, passer à la version d’Angular 1.5.x qui intègre les composants, et transformer les directives en composants. 

   • Utiliser le routeur orienté composants via NPM @angular/router

3. Système de module d’Angular 1 :
   • Utiliser le système d’import d’ES6 via SystemJS, car c’est le “module loader” par défaut sur Angular 2. Pour ce faire, il est recommandé d’utiliser JSPM afin qu’il puisse configurer SystemJS, mais aussi car il récupère les dépendances sur NPM, Github ou Bitbucket. Ce qui est un plus pour les projets Front.
   • Migrer son projet en Typescript. Typescript est un langage de Microsoft lancé en 2012 “transpilant” vers javascript qui est un sur-ensemble  d’EcmaScript 2015/2016 qui est statiquement typé avec un typage structurel et graduel (c’est-à-dire qu’il compare 2 objets non pas sur le nom du type dont ils font partie, mais sur les propriétés que les deux types contiennent). Pourquoi Typescript ? Déjà la migration et l’apprentissage sont simples, le refactoring et la complétion dans les IDE fonctionnent bien (IntelliJ/WebStorm, Atom, Visual Studio en tout cas) et les types peuvent servir de documentation. Par contre, pour gérer les librairies tierces qui sont en Javascript, il faut des fichiers d’entêtes appelé “.d.ts” et pour les récupérer, il faut (encore) un package manager du nom de Typings. À savoir aussi que Angular 2 est codé en Typescript et que l’équipe recommande fortement de l’utiliser.
   • Les types : Bannir au maximum le any, typer explicitement les entrées/sorties des méthodes, fonctions, etc. Et éviter les appels dynamiques.
   • Remplacer les $scope.$watch par des get et set.
   • Ajouter des comportements transverses aux méthodes via les Décorators (Ex: Throttle, Memorize, Inject, Debounce, etc.)
4. Angular 2 ! Dans Angular 1 :
   • Mettre en place une application “hybride” grâce à l’UpgradeAdapter qui permet d’upgrader des services et composants Angular 1 et de downgrader et services et composants Angular 2, et migrer les composants de plus bas niveau en remontant jusqu’à la racine de l’application (ng-app).
   • Ng-Forward qui permet d’utiliser les décorateurs de Angular 2 dans Angular 1.

Pour résumer, suivre les bonnes pratiques, utiliser un système de module avec Typescript, migrer les “feuilles” de votre arbres de composants et terminer par le “routing” et le composant de top-level. C’est beaucoup de travail pour une migration de version de framework, surtout qu’il faut être sur la dernière version d’Angular 1. Pour un nouveau projet, la version Beta actuelle, qui devrait passer en Release Candidate très prochaine est plutôt stable et pourrait être utilisée durant la phase de développement du projet. Mais Benoit a préféré répondre que s’il devait commencer un nouveau projet, il partirait plutôt sur du… R***t, mais c’est surtout par rapport aux goûts et préférences de chacun. 

Les slides de la présentation sont disponibles sur le github du présentateur.