26 Nov 2015, 23:59

Retour sur Codeurs en Seine 2015

Aujourd'hui se tenait l'édition 2015 de Codeurs en Seine ; petit résumé de la journée :

  • Test Drive Infrastructure avec Docker (slides ; code):
    • L'idée est d'appliqué les principes du TDD sur la partie infrastructure (versionning, tests, intégration continue, etc).
    • Différents niveaux de tests possibles
      • Tests unitaires : tests au niveau de la fabrication du container en lui même
      • Tests d'intégration : tests du bon fonctionnement des composants de l'infrastructure
      • Mais aussi tests d'acceptance, tests de sécurité, tests de performance, etc.
    • Développement de docker-unit qui permet de tester la bonne exécution d'un docker build en testant le résultat du Dockerfile à chaque étape.
    • Le projet est basé sur dockramp, il est encore jeune mais l'idée est intéressante. L'auteur du projet doit contacter l'équipe Docker pour voir s'il doit continuer ou si cette dernière a déjà des choses dans les cartons.
  • 5 facteurs clés pour l'auto-organisation : l'auteur revient sur l'organisation d'Agile France qui s'est fait dans un contexte particulier. Il en retient 5 clés :
    • Ownership : il a fallu dépasser sa conception "égocentrique" de l'événement pour en faire l'événement de la communauté pour fédérer tout le monde autour du projet
    • Dialogue : passage de la discussion (bruit++) au dialogue (signal++) ; seules les personnes ayant un intérêt sur un sujet donné ont le droit de donner leur avis et de travailler ensemble. Le bruit ambiant généré par les autres est supprimé en les "excluant" du sujet (ou du moins en ignorant leur "moi je pense que...")
    • Leadership ; en prologement du point précédent, plutôt que de chercher un consensus mou, que les personnes intéressées par le sujet prennent le leadership du sujet et avancent. A noter qu'il n'y a pas d'opposition entre auto-organisation et leadership, c'est le passage d'avis vers des intentions.
    • Artefacts : il s'agit de produire des choses visibles et de s'organiser autour de ces artefacts (réunions, etc)
    • Vision : il faut définir un cadre et communiquer autour de ce cadre.
    • En reprenant de bas en haut, un moyen de se rappeler du mot via le terme VALDO.
  • HTTP/2, les bonnes pratiques du web évoluent ; une présentation rapide de HTTP/1.1 et des apports de HTTP/2 avec les principaux apports (push server, multiplexage, priorité des ressources, compression des entêtes, flux binaire plutôt que textuel et https quasi requis de part le support de http/2 dans Chrome/Firefox) et impacts sur nos pratiques actuelles (plus besoin de domain sharding, de concaténation, de sprites CSS ou d'inlining). Par contre, les optimisations d'images, la compression, la minification et l'optimisation des fontes et la gestion du cache restent de mise.
  • Bidouillabilité à l'ère du numérique : Tristan Nitot qui nous parle
    • des débuts de l'ordinateur où ils étaient bidouillables vs les modèles de plus en plus fermés de nos jours
    • des débuts du web s'appuyant sur des formats ouverts vs des sdk "fermés" où en gros on doit demander l'autorisation de...
    • du cloud (dans le sens des offres SaaS) qui n'est rien d'autres que l'ordinateur de quelqu'un d'autre et sur lequel vous n'avez aucun contrôle, dont le code source n'est pas disponible et qui n'est pas bidouillable.
    • Dans le SaaS, le client est celui qui paye pour les données, pas celui qui les fournit (contre un service "gratuit")
    • Tristan Nitot propose le SIRCUS : Système d'Information Redonnant le Contrôle Aux UtilisateurS et ses 7 principes
      • Pas de publicité ciblée
      • Utiliser du matériel que l'on contrôle (Raspberry, CubieTruck, etc en auto hébergement ou à la rigueur chez un hébergeur)
      • Utiliser du logiciel libre (CozyCloud, Owncloud, YunoHost, etc)
      • Utiliser le chiffrement
      • Une UX à la hauteur
      • Interopérabilité
      • Une killer feature que les offres SaaS ne peuvent fournir
        • A ce sujet, Cozycloud réfléchit à croiser les données qui seraient centralisées dans l'instance (ex afficher les noms des contacts en lieu et place de leur numéros sur la facture téléphonique en croisant la facture avec les contacts)
    • Mes enseignements :
      • Même en étant relativement sensibilité à la gestion des données personnelles, cette conférence donne une claque et montre le chemin à parcourir et les enjeux.
      • Toutefois la question de l'auto-hébergement reste un problème ; comment demander et permettre à Mme Michu d'avoir ses données de façon sécurisée ?
      • Par ailleurs, si CozyCloud arrive à tout concentrer en un seul lieu et à croiser les données, quid en cas d'intrusion sur le systmèe (via un hacker ou un cambrioleur ou des forces de l'ordre à la rigueur ?). Qu'est-ce qui est mieux entre une analyse partielle mais permanente des données chez les GAFA vs un risque faible mais un impact très fort si mon instance CozyCloud par ex est récupérée par un tiers, celle-ci contenant nos données ?
      • Il y a peut être des choses intéressantes à faire dans un contexte CozyCloud + VRM.
  • Apache Drill, le SQL pour Hadoop et plus... :
    • Drill permet de manipuler en SQL tout types de données issues d'un cluster hadoop, d'une base de données SQL/NoSQL, de fichiers CSV, JSON,XML, etc. Il permet même au sein d'une même requête de requêter sur plusieurs sources de données.
    • C'est donc du "SQL on everything" avec une logique de schema à la volée en fonction de la requête. Cela peut être distribué notamment dans un cluster Hadoop.
    • A intégrer dans les outils rapidement...
  • AngularJS, the good, the bad and the transition to Angular 2 :
    • Un talk qui présente les bons et mauvais côtés d'Angular V1, une rapide présentation d'Angular V2 et comment migrer
    • Un livre sur Angular2 est en cours de rédaction ; celui sur Angular V1 est dispo => books.ninja-squad.com ; j'ai la V1 mais toujours pas lu ;-)
    • The Good
      • ngHint
      • eslint + plugin Angular
    • The Bad
      • $scope-soup
      • Eviter les conflits de scope parents/enfants via les "ControllerAs"
      • Performances
        • Utliser les bindOnce pour réduire le nombre de watchers
        • Ajouter des "track by" pour éviter de reconstruire le dom d'une vue sur l'autre si on manipule les mêmes objets
        • Utiliser judicieusement ngIf vs ngShow
          • ngIf : détruit le dom et le reconsruit
          • ngShow : cache le bloc mais si celui-ci contient des instructions qui sont calculées, alors elles le seront quand même
        • ng-model-options pour conditionner le déclenchement du cycle de digest/watcher
      • Fuites mémoire ; rajouter des $scope.on("$destroy" ...) pour faire le ménage
    • Angular2
      • Prévoir de l'écrire en ES2015 ou TypeScript
      • Tout est composant
      • Nouveu modèle de template
        • Web Components compatible
        • Web Workers compatible
      • angular-cli
    • Migration vers NG2 dans le cadre d'un projet NG1
      • Utiliser la syntaxe ControllerAs
      • Utiliser les directives pour initier une approche composant ; Angular 1.5 apportera un début de syntaxe "component"
      • Commencer à écrire en ES6
      • ngUpgrade permettra d'utiliser une syntaxe orientée composant et de les "downgrader" en syntaxe Angular 1.
  • Ionic, le framework mobile hybrid carrément addictif :
    • Application hybride = WebView embarqué dans une application native
    • Ionic = AngularJS + Cordova
    • Plugins ng-cordova pour accéder au matériel et fonctionnalités du périphérique
    • Ionic fournit un ensemble d'outil pour aider au développement et au déploiement des applications avec un modèle économique en cours de définition
    • solution manquant encore un peu de maturité ?

Au final, globalement une bonne journée avec une bonne organisation. La diversité des tracks (agile, technologies, web et Java) permettent de trouver son bonheur et d'avoir un programme à la carte. Une bonne formule en somme.

27 May 2015, 09:30

Around the Web - May 2015

API

Misc

  • A day at Devoxx France (in French) : a summary from Xebia about the Devoxx France conference (Java based but not only) and their findings.
  • Mix-IT Web was in Lyon in April, and the M6 Web tech team wrote a feedback in French - Day 1 - Day 2 ; it deals both with tech and agile topics.

Browsers

PHP

UX

  • The Apple Watch: User-Experience Appraisal : a review on how you app should behave (or not behave) on the new Apple IWatch ; transition with iPhone is also managed and the way to dealt with content and how you should manage your interactions.

Web performance

NoSQL, ElasticSearch

  • Elastic released a new (commercial) plugin for ElasticSearch caled "Watcher" and which aims to raise "alerts" when some events occured and according to some conditions, it may generate an action (email being sent, interaction with another system, etc).
  • M6 Web Tech team published a video (in French) about an introduction to Cassandra.

Geolocation

  • Indoor geolocation technology : article (in French) about indoor geolocation technology, describing and comparing Wifi vs NFC vs Beacon vs Magnetic field to provide geolocation.

10 Jun 2013, 22:00

dotScale, synthèse de la conférence

Sur un coup de tête, il y a quelques mois, je m'étais pris une place pour dotScale et poser le RTT associé. En début de semaine dernière, je m'étais interrogé sur mes motivations et ce que j'allais bien en ressortir. Force est de reconnaitre que je n'ai pas été déçu, même si je ne m'attendais pas tout à fait à ça. Les "Dot" conférences se veulent être en quelques sorte les TEDx des techos, on sort donc du format de présentation classique, tout comme l'approche du sujet qui était cloud, big data et scalabilité. Ci-après ma tentative de synthèse.

"Be ready to fail"

Que ce soit Jonathan Weiss (Amazon), Quentin Adam (Clever Cloud) ou encore Barry Abrahamson (Wordpress), on sent qu'il y a une véritable culture de l'échec qui a été adoptée. Loin de sanctionner l'échec comme on peut le faire en France et de vivre dans l'utopie de vouloir atteindre la perfection, le postulat est de dire qu'à tout moment, l'erreur / l'incident / l'échec peut advenir. C'est normal, c'est sain et ça permet d'apprendre. Il faut donc vivre avec et s'organiser en conséquence.

On retrouvera ainsi l'exemple de Netflix qui a tellement adopté cette culture que l'organisation elle-même crée de l'incident pour valider sa résilience. Pour l'histoire, ils vont jusqu'à mettre 1/3 de leur plateforme HS pour voir si elle peut tenir la charge... Cela prend le nom de Chaos Monkey ou de Dystopia as a service.

Quel exemple de maturité sur le sujet de leur part et que de chemin à parcourir pour bon nombre d'entreprises...

"Monitor and get metrics"

Un autre point assez globalement partagé, c'est de tester / mesurer / surveiller. Si ce pré-requis n'est pas satisfait, impossible d'aller où que ce soit et de savoir ce que l'on fait. Les métriques sont aussi bien techniques (consommation CPU, RAM, réseau, etc) que fonctionnels (nombre de ventes, nombre de création de compte, etc)

Résilience

Autre point mis en avant, la résilience du système quant à son activité et ses incidents au travers des quelques pratiques suivantes :

  • Validation permantente de sa capacité à sauegarder/restaurer ses données : Wordpress s'est donné par ex un SLA d'1 heure pour remonter un serveur et un jeu de données associé from scratch. Par ailleurs, la partie sauvegarde représente environ 10% des couts d'infrastructure de Wordpress.
  • Ne pas utiliser la RAM pour y stocker des données un tant soit peu persistante ; si le code/serveur échoue, la données est perdue
  • Ne pas stocker ses fichiers sur un simple FS, ça ne "scale" pas ; des solutions plus élaborées de FS distribuées/intelligents à la Amazon S3 par ex sont plus préférables
  • Contenir au maximum les effets potentiels d'un changement ; que ce soit par des approches modulaires (chaque composant est isolé/isolabe et est au service d'un autre) ou bien le recyclage permanent de ses VM en tuant les moins performances ou encore en déployant un changement sur la population la plus petite du service, la logique veut qu'un changement ne doit impacter dans un premier temps qu'un minimum de personnes/serveurs. Une fois le changement validé, un déploiement à plus grande échelle est possible.

Cloud et coût

Mentionné lors d'un lightning talk de 5mn, le sujet de l'approche "Cloud Costing Driven" a été abordé : comme chaque VM est facturée à l'heure / utilisation, il va être facile de faire la chasse aux couts inutiles (oubli d'arrêt d'une VM de développement le week-end, VM du plan de production de nuit allumée 24/24, etc) ou bien de quantifier finement le coût de tel ou tel changement (le changement X a accru notre consommation de Y %)

Le coût va donc gagner en visiblité et en précision, contrairement à aujourd'hui où la VM a un prix fixe et lissé sur l'année, quelque soit son utilisation.

Autres bonnes pratiques

De façon plus classique, on retrouve :

  • Séparer les process et les données, en considérant énormément de choses commes des données (données utilisateurs mais aussi session, voir les événements en eux mêmes),
  • "Statelessness"
  • Utiliser les technologies qui répondent au besoin et non les technos "hypes" / que vous aimez
  • Ne créer pas des "monstres", ils ne scalent pas
  • Eviter la magie ; ie il vous faut connaitre le fonctionnement de vos applications / framework / ... pour qu'un mécanisme interne ne vous empêche pas de passer à l'échelle
  • "Divide & conquer" : render votre code modulaire et déployer les comme des services les uns aux autres ; par ailleurs pour modulariser vos applications, utiliser un "message broker" (au passage, Cron n'est pas un message broker ; visez plutot Celery, RabbitMQ, Redis & co)
  • Les gros calculs se font en asynchrones
  • Utiliser des reverse proxy comme passerelle / passe-plat entre votre application et les utilisateurs
  • Automatiser au maximum

Autres sessions

  • Gandi.net, via Thomas Stocking, nous a présenté leur technologie TRILL/VNT qui leur permet de s'affranchir des 4096 VLAN traditionnels et en proposé plus de 16 millions (4096^2) en s'appuyant sur des RFC existantes. Leur solution sera bientôt disponible sous license Open Source vu qu'ils voient cette avancée comme n'étant pas un avantage concurrentiel et surtout pour espérer fédérer d'autres acteurs autour. En effet, d'autres implémentations sur la base d'autres protocoles & RFC seraient possibles. Un des points fort étant que leur solution ne demande pas d'infrastructure particulière pour en profiter.
  • Solomon Hykes, à l'orgine de Docker, nous a expliqué le chemin parcouru pour en arriver à cette solution :
    • Livrer du code est une activité pénible et requiert beaucoup de main d'oeuvre
    • Ils se sont inspirés de l'industrie du transport de marchandise, qui a fini par inventer un format unique pour transporter n'importe quel objet d'un point A à un point B : le container.
    • Docker se veut donc le packaging standardisé d'une application et ses dépendances.
    • C'est écrit en Go et cela s'appuie sur les containers LXCE.
  • Mandy Waite, de Google, nous a présenté le projet "big data" qu'elle a mené pendant la dernière Google IO en déposant 500 bornes capables de capter un certain nombre d'informations environementables : bruit, température, nombre de pas, ondes, etc durant toute la conférence. Les données collectées via les bornes (équipement à base d'Arduino) étaient ensuite poussée dans un mix Google App Engine / Google Compute Engine / Google Big Query et Google Storage afin d'être analysées et restituées.
  • Shay Banon, créateur d'Elastic Search, nous a présenté pourquoi il a créé ElasticSearch et plus précisément en quoi un système distribué demandait une approche différente d'un système centralisé et quels étaient les paradigmes associés.
  • Doug Cutting, créateur d'Hadoop, nous a présenté l'écosystème Hadoop ; ayant déjà eu une présentation similaire il y a peu (certes pas par son créateur), le point d'intérêt pour moi a été de voir le lien entre la publication de travaux de recherche (principalement par Google d'ailleurs) puis quelques années après l'implémentation de ces idées dans un modèle Open Source dans le monde Hadoop. Avec une pensée intéressante sur justement cette transition d'une recherche à une iméplementation open source : l'open source permet de rendre qqc accessible à tout à chacun, sous la forme d'une commodité.
  • Joshua McKenty, co-fondateur d'OpenStack, est quant à lui revenu sur la façon dont la communauté OpenStack est organisée et la façon dont elle "scale". Le point majeur de cette présentation étant de voir la liaison entre la culture, la communauté et le code en s'appuyant sur la loi de Conway. La culture façonne la communauté qui à son tour impacte le code.

Au final, une journée étonnante et riche en enseignements. Au delà des technos, c'est au final cet aspect culture qui me parait le plus important / intéressant de valoriser et de voir le chemin qu'il nous reste à faire...