Pour sa deuxième édition, Bdx.io((un événement soutenu par Clever Age)) a réalisé un carton plein avec plus de 500 participants autour de très nombreuses thématiques : développement natif et cross-platform, développement Web, bonnes pratiques, programmation fonctionnelle, sécurité, bases de données… le programme complet((disponible sur la Web App Voxxr)) était alléchant.
Nous étions parmi les visiteurs, voici nos ressentis :
- Grégoire : « de nombreux coups de coeur »
- Boris : « nous devons mieux gérer le offline »
- Pierre et Matthieu : « le développement avec React Native semble prometteur »
- Pour finir : une conclusion sensible
Grégoire : « de nombreux coups de coeur »
Je n’ai pas réussi à choisir spécifiquement une conférence mais j’ai eu plusieurs coups de coeur qui recouvrent bien la variété technique de nos métiers.
J’ai par exemple apprécié l’intervention de Mathieu Parisot sur ES6, même si elle était très rapide. La présentation API Web / REST : apprenez à maîtriser le cache était aussi très intéressante, parsemée d’exemples concrets qui ont su capter mon attention. Côté serveur, j’ai adhéré au discours de mon collègue Arnaud concernant PHP7 mais c’est plutôt le retour d’expérience de Jérémie Monsingon sur ELK qui a attiré durablement mon attention. L’aspect « solution » offert par l’assemblage est très pertinent, et je vais essayer de garder en tête les points d’attention remontés concernant l’important volume de stockage nécessaire pour les logs.
Mes deux coups de coeurs vont aux conférence Stratégies de collaboration avec Git & GitHub d’Alain Hélaïli et Designing Captain Train Mobile Experience de Cyril Mottier. Dans les deux cas, il s’agit de retours d’expérience d’orateurs bien placés pour maitriser leurs sujets respectifs, et cela se sent.
Dans la première, nous avons assisté à un rapide historique sur la création de git par Linus Torvald, puis à une explication des workflows de travail utilisant GitHub. De la création de branche pour chaque feature à l’utilisation des Pull Requests pour partager le code produit, l’orateur a réussi à rappeler l’essentiel de ce qui rend git intéressant sans parler de commandes. Une vraie prouesse.
Dans la seconde, Cyril revenait sur la phase de recherche, création, sélection du design applicatif et visuel de Captain Train. Avec un aperçu privilégié de l’historique du projet, nous avons pu comprendre comment des expériences comme Captain Train, aussi simples soient-elles, sont le fruits de nombreux tests et réflexions.
Boris : « nous devons mieux gérer le offline »
Dans ce genre d’événement, je suis souvent animé d’envies paradoxales : une partie de moi souhaite se lancer à corps perdu dans le dernière librairie SPA((pour Single Page Application, une famille de librairies JavaScript destinées à produire dans le navigateur une grande partie de la logique applicative, utilisant uniquement les échanges avec le ou les serveurs comme support de données, souvent via des API.)) à la mode et produire des sites Web de plus en plus applicatifs et interactifs. Une autre partie de moi se demande ce qu’il advient de cette fabuleuse interaction quand le jeu de contraintes se durcit.
Parmi ces contraintes, on peut imaginer l’absence de JavaScript ou l’utilisateur passant par une liseuse d’écrans. On pense moins souvent, à tort, à la bande passante faible, voire inexistante. Qu’advient-il du Web quand Internet n’est plus accessible ?
C’est un domaine que la technologie explore encore très peu, ou mal, et qui nous rend accros à nos connexions alors que nous consultons très souvent des informations invariables ou pas loin de l’être. Hubert Sablonnière prend l’exemple du programme de votre cinéma : un contenu qui varie peu, sur une base connue et régulière, et qui pourrait être mis en cache. Si nous utilisons le cache naturel du Web, nous ne pourrons plus pousser de modifications or un imprévu est toujours possible et il faudrait un cache invalidable… comment faire ?
Sans dévoiler toute la conférence d’Hubert, que je vous invite à voir dès qu’elle sera disponible en vidéo, les Service Workers agissent comme une couche intermédiaire entre le client et le serveur, côté client, et peuvent faire de nombreuses choses comme de manipuler et mettre en cache (puisque c’est de ça qu’on parle) des contenus. Seule contrainte qui n’en sera bientôt plus une, il faut que le site soit en HTTPS. Un bien maigre effort face à ce nouveau pas vers la « logiciellisation » du Web.
D’autres conférences m’ont intéressé mais c’est celle-ci, je pense, que je retiendrai encore dans quelques années.
Pierre et Matthieu : « le développement avec React Native semble prometteur »
Antoine Hanriat de Azendoo nous a fait part d’un retour d’expérience intéressant sur le développement cross-platform de leur application mobile pour aboutir sur une présentation d’une technologie à la mode : React Native.
Antoine nous a raconté comment Azendoo a fait le choix de développer leur première application mobile sous PhoneGap pour mutualiser le développement Android et iOS. Très vite, ils se sont retrouvé à optimiser de façon très poussée leurs développements afin d’éliminer le ralentissement constaté sur les animations. En effet, PhoneGap possède un seul thread pour l’exécution du code métier et le dessin de l’interface. Le temps gagné par le développement cross-platform est très vite perdu par les phases d’optimisations.
C’est à ce moment qu’Azendoo a entendu parler de Flipboard qui a réussi à faire des animations d’interface à 60fps sur une technologie cross-platform en utilisant un composant Canvas et React Native. Ils ont donc décidé de refondre leur application en utilisant React Native, une technologie jeune (encore quelques bugs) et ambitieuse dont nous parlions il y a quelques mois et qui vise à piloter les interfaces natives en JavaScript, tout en permettant de faire le pont avec des modules complètement natifs lorsque le besoin est très spécifique.
Pendant la présentation, Antoine nous a montré que certaines modifications dans le code peuvent être testées juste en rafraîchissant la page, sans passer par une compilation chronophage et que l’on pouvait, sous certaines conditions, faire une mise à jour de l’application sans passer par les plateformes AppStore et Google Play avec des temps de publication plus ou moins (parfois très) longs.
Entre la techno prometteuse, les très bons exemples et la pédagogie de l’orateur, nous avons été conquis.
Pour finir : une conclusion sensible
La conférence s’est terminée par une prise de parole de Thomas Parisot, venu s’exprimer sur son expérience à la BBC et le monolithe (de code, culturel, en terme de processus) que cela peut représenter. À la place, Thomas a fait défiler des photos de ses voyages en racontant des anecdotes qui parlaient du principal monolithe sur lequel il a travaillé ces derniers mois : lui-même.
Brouillonne sur la forme (multipliant les cafouillage et les références à des points futurs), son intervention était extrêmement sensible sur le fond. Il y parlait de dépassement pour vaincre ses peurs ; d’expériences subies qui apprennent la résilience mais qui changent, aussi, parfois ; de recul et de subjectivité. Bien qu’un peu iconoclaste, ce dernier point de vue ramenait l’auditoire à des thématiques plus humaines. L’accueil fut mitigé : certains pleuraient, secoués par leur écho personnel. D’autres dénonçaient un scandale, l’allocution étant aux antipodes du reste de la journée.
Pourtant, au milieu de ces conférences techniques qui nous poussent à toujours en apprendre davantage, à toujours innover, à toujours être au sommet de nos capacités pour le bien de nos projets, son intervention avait le mérite indéniable de rappeler qu’au centre de tout cela, il y a des hommes et des femmes qui vivent.
C’était une belle conclusion.
