En route pour la dernière journée à DevoxxFR 2013 ! Au programme aujourd’hui, de la technique mais aussi beaucoup de méthodologie pour être plus productif.

IDE Java : astuces de productivité pour le quotidien

Xavier Hanin, le concepteur de Ivy, nous a proposé une petite démo de son utilisation quotidienne des IDE Netbeans, IntelliJ IDEA et Eclipse.

Un seul mot d’ordre pour la productivité : utilisez votre clavier ! Xavier Hanin a récolté avec l’aide d’autres personnes tous les raccourcis clavier les plus utiles à connaître absolument. La cheat sheet est disponible ici. Penser aussi à l’utilisation des meta-raccourcis (ctrl+3 pour Eclipse), on mémorise plus facilement le nom d’une commande que son raccourci clavier.

Animez vos pages HTML5: un tour d’horizon complet des techniques d’animation en HTML5

Une conférence animé par Martin Gorner, de chez Google, qui nous a présenté toutes les technologies d’animations pour le web (non, pas de Flash !!!).

Pour commencer, les transitions CSS3. Pour beaucoup de monde, CSS se limite à de la mise-en-forme conventionnelle du layout de la page. Depuis sa version 3, CSS permet beaucoup plus que ça, et notamment des fonctionnalités d’animation d’objets (rotation, translation, homothétie…). Les exemples de la conférence sont assez impressionnants à ce niveau, avec quelques lignes de CSS (et sans Javascript !), on peut faire de l’animation à la fois 2D et 3D. Un exemple ici

Ensuite, le SVG À nouveau, beaucoup restreignent SVG uniquement à ses capacités de dessins. Comme CSS, il permet aussi d’animer l’image obtenu. Et encore une fois, un résultat assez surprenant au final pour juste du XML (toujours sans Javascript !). Voir ici (cliquez sur la page pour lancer l’animation).

Les 2 méthodes précédentes souffrent d’un défaut : on doit connaître l’intégralité de la scène à la création de l’animation, et ce à chaque étape de l’animation. Impossible de créer dynamiquement une image à partir de données utilisateur ou d’utiliser un moteur physique (comme Box2dWeb par exemple). Si on souhaite faire des choses dans ce style, il faut utiliser d’autres technologies.

La 1ère, les canvas HTML5 Les canvas vont permettre de dessiner en Javascript via des primitives (points, traits, courbes de Bézier…). On peut aussi utiliser des images SVG pour éviter d’avoir à tout redessiner à la main. Petite astuce au passage, ne pas utiliser un simple timer pour la boucle d’animation, sous peine de rafraîchir en continu à 60Hz et de surcharger le CPU y compris onglet ou navigateur réduit. Mortel pour l’autonomie sous mobile ! Préférer le gestionnaire requestAnimationFrame qui calculera tout seul quel est le moment opportun pour afficher une nouvelle frame. Un exemple ici.

La 2nde méthode, c’est le WebGL. Carrément du OpenGL dans le navigateur ! Et vu qu’OpenGL est plutôt assez cryptique et difficile à maîtriser, il existe des librairies d’abstraction pour faire votre scène, comme Three.js. Textures, jeux de lumière, emplacement des caméras, moteur de rendu… Tout devient à votre portée. Encore un exemple ici (cliquez sur les icônes Androïd).

Vous l’aurez compris, commencez à creuser des trous (bien profonds si possible) pour Flash et autre Silverlight. Et aussi une jolie tombe bien fleurie pour IE 10, qui peine encore sur ces nouvelles technologies.

Conférences diverses

3 conférences intéressantes, mais pas assez de contenu pour en faire 3 chapitres, donc je fais un tir groupé.

Les lambda arrivent. En attendant, êtes-vous sûr d’avoir compris les génériques?

Un quicky par Henri Tremblay, qui revient sur Java 8 et les lambdas, et nous fait faire une plongée dans les generic de Java 7, histoire d’être bien sûr d’avoir tout compris et d’encaisser le coup avec la version 8. Avec les lambdas, le concept de generic va en effet vraiment être au centre du monde.

Quelques petits conseils pour les développements futurs, comme s’interdire de retourner du wildcard dans nos fonctions, ou sur comment aider le compilateur à faire son inférence de type sans céder au « @SuppressWarnings(“unchecked”) ».

The Spring Update: Looking at Spring 3.1, 3.2, and 4.0

Conférence de Josh Long sur le futur de Spring.

Dans la version 3.1, on trouve déjà la possibilité de configurer le conteneur via du pur Java, qui vient compléter le XML et les annotations. Apparaissent aussi la notion de profiles, pour configurer le conteneur en fonction de l’environnement, tout en évitant le découpage dans les fichiers multiples comme auparavant. Et enfin, la gestion des caches dans l’application.

On continue avec la version 3.2, qui voit apparaître la notion d’asynchronisme dans la partie webmvc, ou encore la négotiation de contenu. Et enfin, la partie test s’enrichit d’une API de mock pour pouvoir tester nos contrôleurs sans conteneur de servlet !

Pour la version 4.0, il va y avoir du lourd, du très lourd… Intégration de Groovy comme DSL pour la configuration et de Java 8, intégration des architectures orientées message, event driven, websocket, RESTTemplate, controleur non bloquant, assets pipeline… Du lourd, du lourd, du lourd ! Vivement la sortie, prévue pour fin de cette année (après la sortie de Java 8).

Groovy et les DSLs statiquement typés

Cédric Champeau (committer Groovy) et Guillaume Laforge (concepteur de Groovy) ont présenté une fonctionnalité très intéressante de Groovy 2 : le type check. Groovy étant un langage dynamique, le contrôle de typage n’est pas fait à la compilation, mais à l’exécution.

En théorie, côté développement, ce manque de contrôle est corrigé par suffisamment de tests unitaires. Le problème se pose quand on utilise Groovy pour écrire des DSL. Les DSL sont des mini-langages, mais à destination d’un domaine ultra-spécifique et surtout destinés à être utilisés par des utilisateurs finaux, et non des développeurs. Les tests unitaires sont hors de leur portée, mais on aimerait bien contrôler fortement les entrées utilisateur pour éviter des plantages de l’application. Avant Groovy 2, ceci était impossible. Depuis la version 2, on peut utiliser les annotations « @TypeChecked » , « @CompileStatic » et « @DelegatesTo » pour faire revenir du contrôle statique à la compilation.

Les secrets des Géants du Web - 10 pratiques pour mieux travailler

Ludovic Cinquin, co-auteur du livre « les géants du web », vient ici nous faire la présentation du mode de fonctionnement utilisés par les grands du web actuel (Google, Amazone, Netflix…), qui est totalement différent de celui des sociétés plus conventionnelles.

La 1ère grosse différence avec nos sociétés classiques : le nombre d’utilisateurs touchés. Facebook, c’est plus de 1.3 milliards d’utilisateurs. Netflix, c’est 1/3 de la bande passante des État-Unis. Ceci va encore s’accentuer dans les années à venir, avec de plus en plus d’objets connectés, et surtout connecté en permanence, et non plus ponctuellement. Et pour ne rien arrangé, il y a eu un renversement de situation depuis les années 2000. Avant, des activités réelles (comptabilité, gestion des stocks…) étaient transposées dans le monde de l’informatique. Aujourd’hui, on crée des services à partir de l’informatique existante. La plupart des modes de fonctionnement connus sont donc à revoir dans de telles conditions.

À la recherche des fortes compétences.

Pour pouvoir continuer à fonctionner, ces entreprises doivent d’abord être capables de recruter les meilleurs.

Pour ça, le niveau d’entrée est extrèmement élevé, avec des tests techniques très poussés (calculer une racine carrée avec des opérations basiques, écrire un programme en C qui calcule le temps de changement de contexte sous UNIX…).

Ces entreprises tentent aussi le recrutement par une communication massive de toutes ses pratiques, des conditions de travail en passant par les projets possibles (via des publications en open-source). Elles cherchent à attirer les personnes motivées par ces défis.

Toujours plus gros

Une problématique des grosses entreprises du web, c’est aussi la taille des services proposés : ils deviennent de plus en plus gros.

Auparavant, pour des raisons de coûts, on utilisait massivement le progiciel. Sauf que le progiciel est souvent très générique, sous des architectures « old-school » et avec des modèles économiques généralement basés sur des licences. Dans le monde des gros, c’est un modèle totalement impossible à reproduire. Le générique n’est pas optimisé et s’effondre à forte charge. Les architectures centralisées ne sont pas scalables. Les coûts de licences sont rédhibitoires avec 1 million de serveurs. Les géants sont donc passés d’un monde « buy » à un mode « build » : ils n’achètent plus ce dont ils ont besoin, ils le fabriquent. C’est ainsi qu’on a pu voir arriver Cassandra, BigTable, Hadoop…

Avec le problème de scalabilité est aussi arrivé la limite du matériel. Même le plus gros serveur disponible au Monde ne peut suffir aux besoins de ces goinfres en capacité de calcul. Ils sont donc passés sur des modes de fonctionnement basés sur de petites configurations, mais en quantités énormes. Il est alors impossible de gérer un parc de 10.000 voire 100.000 machines comme on gère un parc de 10 serveurs. Toute l’architecture du SI a du être revue, y compris les méthodologies. L’automatisation y devient obligatoire.

Il devient aussi impossible de garantir le zéro défaut sur de tels systèmes. On doit donc considérer que le système subira forcément des défaillances (Netflix : « The best way to avoid failure is to fail constantly »), et agir en conséquence. On doit intégrer les pannes potentielles bien en amont dans la chaîne, avec une réflexion sur les effets possibles d’une panne et la priorisation de la capacité de calcul, mettre en place des approches différentes pour s’assurer la cohérence du réseau (« eventual consistency ») et gérer la panne nativement dans l’application (mode light comme dans GMail) plutôt que dans le matériel. Certains vont même jusqu’à injecter des virus dans leur réseau pour regarder comment se comporte le système (Simian Army de Netflix).

Toujours plus vite

Une autre problématique des sociétés conventionnelles : combien de temps prend le déploiement en production sur la modification d’une seule ligne de code ? Généralement plusieurs mois voire années… Ceci est bien entendu totalement impossible pour les géants du web. Ils ont depuis longtemps mis en place de l’utomatisation complète, du déploiement continu et du one-click-deployment. À titre d’exemple, Facebook procède à 2 mises-en-production par jour, avec une moyenne de 2.3 millions d’utilisateurs par ops.

En plus, avec un parc de 100.000 machines, la pré-prod… c’est la prod ! On doit donc être capable de revenir en arrière à tout moment, et procéder à des « canary releases » (détournement d’une partie du trafic pour tester la nouvelle version sur un panel restreint, et rollbacker au moindre signe de problème).

Les risques de mise-en-production sont aussi réduits, par des changements petits mais fréquents à la place des quelques rares changements monolitiques des structures conventionnelles. Les géants utilisent aussi la notion de Minimum Viable Product : un produit minimaliste mais qu’on peut déjà commencer à déployer et à tester avec de vrais utilisateurs. Cela permet en plus de recueillir très tôt le profil type et les attentes des utilisateurs. Pour autant, un MVP ne doit pas être un proof-of-concept, mais avoir toutes les qualités logicielles de la future application (un POC ne devrait jamais finir en production).

Des artisans du code

Les PDG des géants du web sont avant tout des développeurs. Et savent très bien que rien ne se fait sans développeur. Cela se ressent dans la gestion des équipes, les salaires des développeurs sont plus élevés que ceux des personnes non dev (gestion, marketing…), les conditions de travail optimisées pour la productivité (les toboggans Google, les openspaces Facebook…). Ces entreprises mettent aussi en place des méthodes de travail basées sur le partage des connaissances, via des revues de code, du mentoring, des hackatons, des contributions à l’opensource ou par du 20%-time.

Pour conclure, ne pas oublier que Google était déjà Google avant d’être Google. Ces méthodes de travail sont applicables même sans être un géant du web, et surtout si on veut en devenir un.

Winter is coming

Aurélien Pelletier et Didier Girard nous ont présenté comment ne pas pourrir en entreprise, ie. être capable de détecter les nouvelles technologies et de s’y former pour ne pas se laisser distancer.

Pour commencer, un tour des différents ennemis qui peuvent entourer un développeur

• La DSI, à qui on demande généralement des réductions de coûts et qui doit assurer la continuité
• La R&D, qui conduit généralement à des projets avec des problèmes bien connus
• Les architectes, généralement avec beaucoup d’inertie et trop de hauteur (astro-architectes)
• Les ops, qui doivent assurer la production, donc plutôt dans la continuité que l’innovation
• L’externalisation des projets, et la fuite des compétences (aujourd’hui, une banque ou une assurance, c’est majoritairement de l’informatique, donc leur cœur de métier)
• Les analystes, qui font dire n’importe quoi aux chiffres
• Les cabinets de conseil, avec le sempiternel « Oui on sait qu’il y a des problèmes mais ça ira mieux demain » pour ne pas avoir à changer de domaine, donc de clients
• Les intégrateurs, qui ont basés tous leurs business-model sur de la technologie aujourd’hui obsolète
• Les politiques, qui ne considèrent pas l’informatique (salon de l’Agriculture, 300.000 personnes pour un CA en France de 128 milliards; Devoxx, 1.500 personnes pour un CA de 50.000 milliards)

Bref, aucun écosystème propice pour innover. Il faut tout faire soi-même. Les solutions possibles.

• L’auto-formation. C’est et ça restera la méthode la plus efficace. Par contre, ça demande clairement un investissement personnel, souvent peu ou pas reconnu.
• Le mouvement DevOps. Automatiser, mettre en place du déploiement continu. Sans ça, pas moyen de se donner du temps pour le reste.
• La taille des équipes : si on ne peut pas nourrir l’équipe avec seulement 2 pizzas, c’est qu’elle est trop grosse. Une grosse équipe a trop d’inertie pour y intégrer de l’innovation.
• Faire des béta. Mais béta ne veut pas dire pas stable, seulement que c’est en test chez des early-adopters. Cela permet de tester rapidement des choses, sans prendre trop de risque ou perdre trop de temps.

Côté technologies, les entreprises françaises se sont généralement toutes bâties sur des ressources qui ont été rares et chères (RAM, CPU, espace disque…) mais qui ne le sont plus. Les ressources IT ne représentent plus rien aujourd’hui. Il faut donc construire un nouveau modèle. 3 changements majeurs sont à prendre en compte rapidement pour ne pas mourir :

• Le cloud : fini les stocks de machines en interne, tout externaliser. On économise en plus la maintenance.
• Le web : tout est orienté web aujourd’hui. Se tourner rapidement vers HTML5.
• La mobilité : on est tous connecté. Penser au multi-screen et au responsive design, la majorité des 1ers contacts ont lieu aujourd’hui via mobile.

Pour bien choisir les futurs technologies et se lancer sur une nouvelle sans courir trop de risque, il faut bien analyser le marché.

• Commencer par voir comment se comporte la communauté, sa rapidité à répondre à une question sur la mailing-list, les fréquentations du GitHub, si des personnes seront motivées pour la TMA plus tard…
• Définir la maturité de la nouvelle solution.
• Analyser l’adoption courante de la technologie.

Pour le test de maturité, 2 tests à réaliser :

• Qu’est-ce qu’un junior est capable de sortir en 1 journée ? Plus il peut sortir de choses, plus la documentation sera bonne, les concepts pas trop compliqués, les dépendances limitées…
• Qu’est-ce qu’un sénior est capable de faire en 30 min ? Ici, c’est surtout l’intégration de la techno à l’existant qui sera testée, comme l’intégration continue ou les outils de build.

Pour le test d’adoption, on peut utiliser Google Trend. Ne pas chercher uniquement le nom de la technologie, mais par exemple « tutorial technoXXX », c’est un meilleur signe de l’activité et de l’adoption du système. Il faut investir dès que le projet part en phase exponentielle : avant on prend trop de risque, après on est déjà en retard par rapport à la concurrence.

Voilà, c’est tout pour cette année. Fabuleuse DevoxxFR 2013. Un grand merci à tous les organisateurs, et à l’année prochaine !

Journée 1 — Journée 2