Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

La semaine dernière, j’ai gagné une entrée à la conférence JS.Everywhere grâce à un article sur RudeBaguette. Merci aux organisateurs de m’avoir donné cette opportunité de participer. Le planning était alléchant et je n’ai pas été déçu, que ce soit par les conférences ou par le salon en lui même. Il y a avait de plus quelques pointures du web, comme par exemple Douglas Crockford (évangéliste célèbre du Javascript) et Tristan Nitot (fondateur de Mozilla Europe).

Au niveau logistique, tout s’est bien passé : les conférences avaient lieu au Tapis Rouge, un hotel plutôt classe dans le Xe, à Paris. La nourriture et les cafés n’ont pas manqués toute la journée. Les conférences étaient à l’heure, et elles se sont toutes globalement bien déroulés (à 2-3 soucis techniques près, comme toujours). Les écrans étaient gros, on y voyait bien, et on entendait bien les conférenciers. Bref sur le plan pratique, félicitation aux organisateurs qui pourront difficilement faire mieux.

Au niveau des conférences, c’était très bon également. Certaines étaient pour tout le monde, mais pour la majorité des autres, il fallait choisir une conférence parmi 4. Toutes ne m’intéressaient pas, mais j’ai parfois regretté de ne pas avoir le don d’ubiquité. J’ai choisi de faire des conférence sur un peu tous les sujets : scalabilité, applis mobiles, sécurité, bonnes pratiques…

Qu’en retenir ? Le mieux c’est de vous parler un peu des conférences auxquelles j’ai assisté. Je ne suis clairement pas un expert sur tous les sujets, autant le dire tout de suite. Mais c’est l’occasion de faire un tour d’horizon de ce qui se passe dans plusieurs domaines. 

L’architecture matérielle de grosses applications web

La journée a commencé par une présentation faite par Pierre Gilot, de chez Amazon, sur la conception de grosses applications qui ont besoin de grosse capacité, et de bien scaler. Comme Vimeo et SoundCloud, qu’ils hébergent.
Comment concevoir des applications de ce genre ? 3 choses essentielles selon lui :

  • Concevoir pour planter
    L’appli doit être conçue pour gérer les plantages : ça arrivera tôt ou tard. Il faut quand même continuer à fonctionner au mieux. Certaines boites comme NetFlix utilisent Chaos Monkey, une application open source qui tue de manière aléatoire des process EN PRODUCTION pour simuler des plantages, et obliger l’appli à être conçue pour gérer ça.
  • Peu de couplage physique
    On nous a présenté comment concevoir l’archi d’une grosse application, à travers l’exemple d’un Youtube-like. Comment faire pour qu’une telle appli scale correctement ? En découplant les entités physiquemment : une entité pour la communication avec le client, une entité pour recevoir les vidéos, une entité pour les encoder et éventuellement les raccourcir… Plus de détails sur la page d’Amazon si ça vous branche. Ils présentent différents type d’architecture pour différents types d’applications.
  • Du NoSQL
    Le problème du SQL, c’est que ça ne scale pas bien quand le nombre de requêtes augmente, au contraire du NoSQL, qui scale linéairement avec le nombre de requêtes. De plus, le NoSQL chez Amazon propose une latence < 10ms quoi qu’il arrive, donc des temps de réponses très bons. Le speaker présentait donc le NoSQL comme solution pour scaler, dommage qu’il n’ait pas parlé des sacrifices qui sont faits pour en arriver là. Si vous n’avez jamais entendu parler de NoSQL, jetez un oeil à ce que proposent MongoDB et CouchDB.

Architecture javascript full stack avec Wakanda

A suivi une conférence sur le design d’une architecture JavaScript full stack pour des applications business. C’est à dire une application que n’aurait que du JS chez le client, le serveur, et pour communiquer avec la base de données. Un tel design pourrait être une solution au problème des autres architectures, que ce soit pour du PHP, du Ruby ou de l’ASP, qui sont obligées d’utiliser plein de langage et d’outils. Ca a été l’occasion de parler de la solution développée par 4D, organisateur de l’évènement (promis, après on a eu des conférences non sponsorisées). Il s’agit de Wakanda.

Le but du logiciel est de gérer le design de l’appli via un editeur WYSIWYG, le design des entités en base, ainsi que d’écrire le code serveur depuis l’IDE (avec un serveur similaire à du nodeJS), et de déployer l’application… Une fonctionnalité très sympa, c’est celle de pouvoir faire des drag-n-drop d’une entité vers un widget : quand on fait glisser l’icone « Client » vers une listbox, l’application sait que l’on veut remplir la liste avec tous les clients. Après, on customize pour obtenir le résultat voulu, mais une bonne partie du travail est mâché.

Je suis pour le moment partagé sur cet outil. C’est une bonne chose de voir des solutions javascript full-stack émerger. C’est une bonne chose de voir que des outils de ce genre soient de plus en plus présents : cela montre que le web se dote d’outils de qualité pour résoudre des problèmatiques pour lesquelles il est de moins en moins possible de bricoler, comme c’est encore le cas actuellement pour pas mal de choses. Le web a beaucoup de retard par rapport à l’informatique industrielle à ce sujet, et ce genre d’initiatives me rend plutôt optimiste pour l’avenir.

De l’autre côté; il y a mon expérience de développeur. Pour avoir travaillé en C# et WPF, c’est à dire avec des outils .Net qui permettent de faire des choses similaires (glisser-déplacer d’entité et hydratation « magique » des widget, entre autres), je reste dubitatif. En WPF, on passe beaucoup de temps à se documenter pour arriver à modifier des comportements triviaux pour remplacer les comportements de base, que l’on utilise au final très peu. Au lieu de gagner du temps, on en a passé autant qu’avant, mais il a fallu se former sur des API peu intéressantes. Dans mon expérience (un gros projet en SSII, quelques milliers de jours hommes de dev), le WPF, qui était au départ une bonne idée, s’est donc rapidement révélé contre productif. J’espère que Wankada, passé l’euphorie initiale, saura se montrer plus convaincant sur cet aspect.

Les applications pour télévision

La conférence sur les applications pour télévision ne m’a pas convaincu. J’ai eu un peu de mal avec le speaker, qui nous balancait des Ferrero Rocher sans que l’on comprenne vraiment pourquoi. Parfois pour féliciter les interventions pertinentes, parfois pour réveiller une salle qui s’ennuyait un peu.

Le côté qui peut sembler attirant, c’est le marché nouveau : tout est à faire dans le monde des applications pour télévision. Mais côté avantages, ça s’arrête là, et l’enthousiasme est largement calmé par les inconvénients qu’il peut y avoir à concevoir son application pour une telle plateforme :

  • Côté développeurs, le monde des applications pour télévisions est difficile d’accès : chaque constructeur a son propre SDK (gratuit pour la plupart il me semble). A l’heure actuelle, il n’y a aucun standard. Il faut donc concevoir une application par marque de téléviseur, ce qui est une première barrière.
  • Les SDK cassent régulièrement la rétro compatibilité de leurs API, rendant inutilisables les applications non mises à jour. Pas très glamour.
  • Côté utilisateurs, ça n’est pas mieux : les gens n’utilisent pas les applications disponibles sur leurs téléviseurs. Soit parce qu’ils ne sont pas au courant qu’il y a des app store, soit parce que cela ne les intéressent pas. Bref, les applications pour téléviseurs n’ont pas l’air très utilisées. Côté pénétration de marché, celui des smartphone/tablettes semble bien plus attirant.

En plus de tout ça, Douglas Crockford a été assez critique sur ce type d’applications : pour lui cela n’a pas de sens de mettre des technologies très changeantes comme les technologies web dans du matériel censé durer au moins 10 ans comme les télévisions.

Internationalisation en Javascript

J’ai raté les conférences de Sebastian Golasch (@asciidisco sur Github et Twitter) sur l’internationalisation. Par contre, sa présentation est sur le web.
C’est une problèmatique importante et qui va probablement se développer dans les années à venir, étant donné l’expansion du javascript côté client comme côté serveur. Pour le moment, peu de choses existent pour faire de la « vraie » internationalisation, c’est à dire gérer correctement la pluralisation, les genres, les dates, les nombres… en javascript.
Sa présentation était axée autour de 2 librairies :

  • messageformat.js, qui vise à résoudre le problème des genres et de la pluralisation
  • globalize.js, qui cherche à gérer l’internationalisation des dates et des nombres.

Je vous invite à regarder la présentation de Sebastian ainsi que les pages Github de ces 2 librairies pour aller plus en profondeur sur le sujet.

La suite de mon compte rendu dans un second article, la semaine prochaine.

Répondre

Unable to load the Are You a Human PlayThru™. Please contact the site owner to report the problem.