Espace disque manquant

Je suis tombé il y a quelques mois sur un comportement bizarre de Windows 8. L’explorateur Windows de ma Surface Pro me faisait clairement voir que je n’avais plus de place :

image

Un coup de WinDirStat pour voir ce qui me bouffe autant d’espace, et là… surprise ! La somme des fichiers vus par l’utilitaire est très loin des 110 Go censés être utilisables.

image

Il me manquait donc 50 Go quelque part. Après avoir fait le ménage, je remarque qu’au fur et à mesure que je libère de l’espace, quelque chose le consomme, et une demi-heure après, je suis systématiquement avec des avertissements systèmes parce que je n’ai plus de place !

Après avoir désactivé un tas de processus, il se trouve que c’est le mode hors connexion pour les fichiers réseau qui posait problème. Vous savez, cette fonctionnalité qu’on active comme ceci :

Image de la commande Toujours disponible hors connexion

Elle vous permet d’avoir accès à un partage réseau donné y compris lorsque vous êtes déconnecté, et Windows se charge de synchroniser vos modifications et celles en provenance du réseau lorsque vous vous rebranchez. Plus de détails sur http://windows.microsoft.com/fr-fr/windows/working-with-network-files-offline.

Il se trouve que dans certaines conditions, cette fonctionnalité recopie encore et encore les fichiers alors qu’ils sont identiques (dans mon cas, le contenu synchronisé ne faisait que 2 Go, mais la consommation finale était de plus de 50 Go). De plus, cela est fait d’une manière qui rend ce contenu invisible aux explorateurs de fichiers et autres utilitaires de lecture du contenu du disque dur.

Je me disais que ça valait un petit blog, parce que j’ai trouvé très peu d’explication sur ce comportement sur internet. Juste la réponse de ChrisInEdmonton sur http://superuser.com/questions/61880/windows-7-missing-free-hdd-space, et encore fait-il simplement référence à ce qui posait problème.

Pour la correction, très simple : allez dans le gestionnaire de fichiers synchronisés et désactiver la synchronisation des fichiers réseau. Puis, si vous n’avez pas été vaccinés, réactivez-là en priant pour que le problème ne se pose plus. En ce qui me concerne, c’est désormais un batch qui synchronise les fichiers chaque semaine, comme ça je sais exactement ce qui se passe…

Posted in Retours | Tagged , | Leave a comment

BreizhCamp 2014

Quelques retours sur la conférence BreizhCamp de fin mai. Cette année encore, deux jours de conférence multi-technos, dans une super ambiance, festive et sérieuse à la fois. La veille, il y avait également une journée “for kids”, où les intervenants apprenaient aux heureux et jeunes veinards comment programmer un NXT 3 (robot Lego), coder en Scratch, etc. J’aurais bien aimé pouvoir venir avec mes enfants…

Attention, les notes sont fournies “as is”. Pas de reprise de contenu, peu de remise en forme. C’est du brut…

Keynote jour 1

Présentation du changement de Microsoft, qui est de moins en moins vu comme le grand méchant loup. Comme quoi, ça met des années avant de se savoir, mais ça finit toujours par arriver.

Partie de cache-cache (Fred Bouchery)

A partir de 4 secondes de temps de chargement, on perd 25% d’utilisateurs.

On trouve des caches à tous les niveaux : navigateur, proxy, reverse-proxy, serveur applicatif, base de données ou systèmes externes. Et de tous types : cache de navigateur, d’OP code, partagé, etc.

Expires est trop vieux, et devrait être remplacé par Cache-control dans les entêtes http, même si le dernier est compatible avec tout. Utiliser ou le ETag ou le LastModified, mais les deux ensemble, cela n’a pas de sens. Le souci est surtout que les serveurs de cache, dans ces cas, n’auront pas un comportement normalisé.

Problème : l’empilement non maitrisé des caches. On a vite tendance à se retrouver avec un cache à tous les niveaux d’une architecture. C’est du gâchis, mais ça force aussi à des manipulations très complexes pour purger les caches lorsque c’est nécessaire pour le développement par exemple.

Conseil : mettre toujours un Cache-control et ne pas laisser les caches prendre leur comportement par défaut.

L’enfer du CRTL+F5 pour vider le cache.

F5 envoie un Cache-control : max-age = 0 et un If-Modified-Since et le serveur renverra un 304 pour dire que la page n’a pas changé depuis (sans contenu, bien sûr)

CTRL-F5 envoie un Cache-control : no-cache (et un pragma : no-cache, qui ne sert plus à rien depuis longtemps)

Problème : tout ça ne fonctionne pas avec AJAX. Après le window.onload, le navigateur prend dans son cache. Et il n’y a pas de moyen de gérer ça à part demander à l’utilisateur de purger manuellement son cache dans la configuration.

Conseil : toutes les ressources statiques devraient avoir un Cache-control, de préférence public de façon qu’une ressource soit mise en cache à destination de plusieurs personnes. Et si on fait une modification, il vaut mieux carrément changer le nom ou ajouter un paramètre pour être sûr que la nouvelle version sera prise (pour le navigateur, c’est une nouvelle URL).

Problème : les pages dynamiques doivent être associées à un Time To Live.

Le hit ratio se dégrade souvent la nuit car comme il y a moins de requêtes, donc le Time To Live fait que le cache a moins souvent la donnée nécessaire. Mais ce point n’est pas grave, car il n’a pas d’impact sur la performance. Si on augmente le TTL, on augmente le hit ratio, mais on congèle les données et ça prend beaucoup de mémoire.

Conseil : faire deux niveaux de cache, chaud et froid, respectivement pour les pages dynamiques et les pages qui ne changent que très peu.

Comment faire une politique d’éviction, de façon à purger le cache pour récupérer de la mémoire ? Il ne faut pas prendre que celles le plus demandées, car ça peut être juste un pic local dans le temps, mais aussi la taille, etc. Le mieux est finalement de sharder pour augmenter la mémoire totale du cache. Il faut aussi supprimer les paramètres qui font varier l’URL mais pas la page.

Conseil : le Vary : Accept-Encoding permet de spécifier les préférences d’algorithmes de compression des pages, mais du coup créent d’autant plus de variance. Il est donc recommandé de l’enlever et de demander tout le temps du gzip, supporté par tous les navigateurs.

Conseil : pour rafraîchir le contenu, ne pas effacer le cache, car ça provoque un phénomène de ruée (thundering herd), et tout le monde se retrouve d’un coup sur le serveur. Il vaut donc mieux périmer artificiellement le contenu avec un stale-cache, pendant qu’en même temps, on envoie le nouvel ordre au serveur. Une autre solution est de mettre des miss pour les adresses internes. Le développeur, du coup, ne passe pas par le cache, réalise le traitement sur le serveur, et remet de fait à jour le cache. On peut également mettre à jour de manière active le cache. La pré-construction du cache permet de s’assurer aussi que les crawlers robots d’indexation ne s’arrêteront pas d’indexer car ils se retrouvent à passer trop de temps à passer sur toutes les pages du site.

Modification de design : quand toutes les pages sont modifiées, il faut faire morceau par morceau, en faisant par exemple du crawling, en générant des miss, etc. de façon asynchrone. Il faut alors planifier complètement cette opération.

Edge Side Include (esi:include) permet de mettre en place des caches partiels. Du coup, chaque partie d’une page a une durée de cache différente.

Trois solutions se démarquent pour les caches partagés, de proxy : Varnish, Nginx et Squid (un peu plus vieux). Apache est un peu à la traîne, mais de nouvelles versions arrivent. Nginx est encore plus performant que Varnish pour les ressources statiques et comme il s’agit d’un vrai serveur web, il peut faire du HTTPS. Il peut également utiliser Redis comme backend de cache. Varnish monte, et est très fonctionnel.

Si majorité de contenus privés, il faut faire le cache au niveau applicatif. En utilisant par exemple MemCached en sharding. Le sharding est obligatoire, sinon on a des risques de désynchronisation, car deux serveurs peuvent avoir leur cache, mais un peu différent de l’autre, et du coup d’une requête à l’autre, même rapidement, on risque de ne pas voir la même page, même si elle est mise en cache. A part MemCached, il y a aussi Redis, mais ce dernier est un peu moins performant, même s’il permet de faire de l’asynchrone, du message queuing, du multi-taggage, etc.

Le Content Delivery Network consiste à répartir des contenus statiques un peu partout dans le monde pour servir l’utilisateur au plus vite. Ce n’est pas vraiment un cache, mais optimise les temps de chargement. Il permet de séparer les sites internationaux.

Utiliser un cache applicatif intégré au serveur, comme APC sur PHP, est beaucoup plus performant que même un Memcached, mais est en général beaucoup plus limité en taille de mémoire utilisable. On peut même détourner le cache de code de PHP pour envoyer de la donnée, en créant un script PHP dynamiquement qui renvoie un tableau de donnée, et qui sera mis dans le cache d’OPcode

Résumé :

  • Maitrisez les caches
  • Trouvez le bon TTL en fonction du contexte
  • Réfléchissez à la stratégie d’invalidation
  • Mettez en place plusieurs niveaux de cache
  • Etudiez le comportement des utilisateurs
  • Suivre les évolutions des solutions

Sur les Single Page Applications, il vaut mieux mettre un no-cache sur index.html. Et pour le développement, on met systématiquement une date de péremption pour ne pas se baser sur le cache. Et pour la production, on utilise du versioning pour forcer le refresh.

Varnish

Varnish est un cache orienté haute-performance, Linux et FreeBSD seulement, et qui peut tourner sur des VMs, mais pas pour de la production.

On configure les politiques de cache avec un DSL, proche du PERL et transformé en C puis compilé pour pouvoir accepter une forte montée en charge. Il expose un automate fini, avec des règles par défaut au cas où.

Par exemple, on peut faire un code qui dit que si la requête contient admin, alors on bypasse le cache. Ou alors, on peut dire que si on détecte que le protocole est en demande d’élévation pour passer en web socket (bidirectionnel), Varnish doit passer en mode pipe (il laisse passer les allers-retours sans s’interposer). On peut également faire de la redirection d’URL par la DSL.

Varnish gère :

  • Le TTL
  • Les variantes (JSON ou XML derrière la même URL, selon le Content-Type)
  • Le gzip

Le VCL (le DSL de Varnish) par défaut ne cache pas :

  • Les cookies
  • Les authentifications
  • Les méthodes autres que GET et POST

Purge de cache possible, par invalidation d’une URL dans le VCL. Le « ban » ne purge pas complètement le contenu, mais le rend inutilisable pendant un temps. On peut donc invalider certaines régions du cache, par URL mais par d’autres critères également bien sûr.

Il est possible de mettre en place un délai de grâce sur un TTL dépassé : on peut donc faire de la très haute dispo en servant du contenu périmé en cas de défaillance du back-end par exemple.

Le load balancing n’en est pas vraiment dans le sens où son but n’est pas de répartir la charge, mais plutôt d’utiliser le « Director » pour maximiser les chances de trouver un cache, par exemple en recherchant le contenu de cache dans plusieurs serveurs différents.

Il y a un shell d’admin qui permet d’agir sur le Varnish, et tout se fait à chaud pour pouvoir être en très haute disponibilité. On peut faire du diagnostic, du tuning, de gérer du VCL, etc.

Les logs traditionnels sont peu utiles, on le sait bien (place disque, illisible, trop ou pas assez, jamais lus, etc.) mais Varnish a une approche un peu plus sophistiqué en stockant les logs en mémoire, et en mettant en place des outils autour pour exploiter ce contenu très complet (il logue tout ce qui se passe).

Le logiciel accepte des plugins, nommés modules, pour l’étendre. Sa version 4, avec des nouveautés suffisantes pour justifier une non-compatibilité ascendante, vient de sortir (Avril 2014). Il utilise deux pools de threads, un pour le client et un pour le serveur, ce qui lui permet de servir en streaming même des clients qui sont en attente de la mise à jour du cache par un autre.

Recette de mise en place :

  • Cacher le contenu statique
  • Configurer la compression
  • Cacher le contenu semi-statique
  • Automatiser l’invalidation du cache
  • Améliorer les backends (entêtes, etc.)

Autres caractéristiques : il y a un framework de test, cela supporte le multi-tenancy, etc.

Durabilité des données par versioning NoSQL

Idée de pipeline de montée en version d’un document au moment où on l’utilise, comme ça la migration est progressive.

Plutôt que de mettre plein de if / else dans le code en fonction d’un numéro de version, il est plus propre de mettre au moins tout ceci dans une seule classe où on regroupe tout ceci, qui n’est pas très élégant.

En gros, l’idée principale est de faire la même chose que pour la montée en version d’un mécanisme de type prévalence objet, en évitant d’avoir la sérialisation qui ne fonctionne plus.

Agile (we are family)

Voir comment les entreprises gérées en famille fonctionnent, par opposition avec des grands groupes.

Les entreprises familiales, déjà, sont quasiment les seules à dépasser la centaine d’année. Or, c’est un critère important de réussite que de durer au long terme.

Dans les grands groupes, il y a souvent une direction « lab » qui cherchent des nouveaux moyens de fonctionner, et qui sont plus libres, précisément parce que le grand groupe a oublié cette liberté. Les petites entreprises familiales ne se rendent pas compte qu’elles sont agiles : elles ne le font pas de manière consciente, et la confiance fait que les gens savent que leur oncle / sœur fait les choses de façon la plus appropriée pour ne pas mettre la famille en danger.

C’est souvent à la troisième génération que les problèmes arrivent, car cette génération n’a pas participé à la difficulté de mise en place, ni en acteur ni en spectateur. Et du coup, il ne la voit que comme une machine à cash.

La structure (hiérarchique ou pas) d’une entreprise doit découler naturellement de son organisation au jour le jour. Ce n’est pas une bonne pratique d’essayer d’en mettre une arbitraire en place.

Le plus important : People + Core values + Enjoy what you work on.

Approche des architectures micro-services (Aurélien Maury – Xebia)

Vert.x utilisé par le conférencier sur les micro-services

Définition en débat : juste des services, mais plus petits. Ou alors, des services automonitorés, faiblement couplés, facilement déployables et self-monitoré (Fred Georges). Ou encore James Lewis qui dit que c’est de la SOA à la façon Unix, c’est-à-dire petits grains.

En gros, ce qu’on fait avec des pipes en Unix, c’est ça qu’on refait mais avec des services qui s’enchaînent les uns les autres. Donc, comme pour des services de fusion de document qui appelle l’URL OData et qui pousse dans la GED, en une seule URL qui en compose trois.

Choisir la portabilité plutôt que l’efficacité.

C’est un peu aussi comme si on appliquait SOLID aux services fonctionnels, en déployant plein de services complètement autonomes, tout en réduisant le couplage fort. On met donc un bus de message le plus simple possible (rien que du publish subscribe pour éviter les travers des ESB) : il vaut mieux un tuyau bête et des extrémités intelligentes (comme pour l’internet neutre). Ce qui veut dire qu’on ne fait pas de route ni d’EIP. On fait une émission libre, avec une topologie flexible. Il faudra voir comment ça s’articule avec du BPMN, car les routes de médiation ne sont pas le problème, mais celles au milieu.

Chaque service a obligatoirement sa propre base de données

Couplage lâche : chaque service s’abonne au fil RSS des autres dont il a besoin.

Chaque service doit être suffisamment petit pour tenir dans la tête d’une personne (pouvoir le réécrire dans le langage qui lui va si problème de personne absente définitivement).

Besoin fort de monitoring si le service ne fonctionne pas. C’est le client qui doit pouvoir remonter que sa dépendance ne fonctionne plus. Ne pas se gêner pour émettre plein de messages, même s’ils ne servent pas dans un premier temps. Ca évite de redéployer plus tard.

Multipliez les versions de service car ce n’est pas un problème. Faire par exemple de l’élection de service. Si c’est le bus qui donne l’annuaire des services, ça ne pose pas de problème.

L’application est supplantée par le système : que propose le SI plutôt que quelle application a la bonne fonctionnalité, voire qu’elle soit partagée (encore pire) ?

Métaphore des flux d’eau, avec des services rapides (torrents), des rivières et des lacs (entrepôts de données). Tout passe par un bus de premier niveau, mais seuls les services de premier niveau prennent les messages dessus. Le reste est pris en compte par un bus secondaire, lui-même éventuellement avec un bus tertiaire pour les logs, audits, etc. qui sont plus longs. Quel que soit le niveau du service, il réémet dans le bus principal.

Avant d’appeler un service, on envoie un message demandant qui le propose. Deux peuvent répondre dans le temps, et il faudra choisir lequel on appelle. Cette élection de service peut se faire de manière régulière. Voir si on peut faire évoluer notre architecture simple, sans annuaire de services, vers ceci.

Le logging et le monitoring sont des services qui sont abonnés à tout.

Pour vendre le principe, parler du décommissionnement progressif, en mettant un proxy qui redirige progressivement.

Les pièges à éviter :

  • Monitoring obligatoire dès le début
  • Ne pas tomber dans le nano-service
  • Faire des déploiements rapides (car il y a plein de services)
  • Ne pas avoir des grosses équipes

Loi de Conway (le logiciel reflète l’organisation qui l’a créé) dit :

  • Micro-services => micro-team
  • Devops mais pas à moitié : l’équipe est responsable de tout, y compris le maintien en condition opérationnel
  • Exigence de qualité et de rigueur (phase d’apprentissage plus longue que juste coder des stories)

Le plus important est que cela permet d’avoir un système à long terme. Un peu comme les cellules du corps humain, il y en a qui sont remplacées à chaque moment.

Important d’avoir un déploiement continu. Et par conséquence, que nous maitrisions le déploiement, donc mode SaaS pour pouvoir bien partir dessus.

Indicator driven : montrer que les dossiers passent bien, que le temps est vérifié, etc.

DropWizard est un outil avec un socle Jetty, Jersey, Jackson, Guava avec du Maven prédéfini, etc. Un peu comme Johan a prévu des artefacts. Connecteurs SPDY, et monitoring pré-défini pour aller plus vite.

Spring Boot permet de faire des applications Spring standalone, avec convention plus que configuration, et même chose pour le monitoring, là aussi avec Metrics.

Vert.x est peut-être le meilleur. Il est asynchrone by design, multi-langage, avec une boîte à outils TCP & HTTP, une structure modulaire, du mode script, et un bus de message communiquant à la base en JSON.

Conseil : utiliser ZeroMQ de préférence si on n’a pas déjà un bus, car il est simple à utiliser, bien documenté et possède tous les patterns nécessaires.

Pour le transactionnel, on oublie, ou alors on fait en deux phases, avec un acknowledge. Pour la granularité, il est intéressant de la baser sur le fait qu’on doit pouvoir remplacer facilement un service.

La différence avec une architecture orientée services est qu’il n’y a aucune intelligence dans le bus. Du coup, est-ce que c’est proche d’une architecture orientée WOA ? Ou même du EDA, d’ailleurs, vu le sens dans lequel c’est expliqué ?

Services de blocage pour dire par exemple de ne pas écouter une ancienne version d’un service, qui est considérée comme plus bonne.

Il faut versionner les messages pour que les services sachent quoi faire.

Il faut le vendre avant de pouvoir mettre en place cette architecture. La mise en place fait énormément de bazar, selon le conférencier. Il faut faire du devops, en remélangeant les équipes pour qu’elles s’alignent sur un même but, qu’elles ajoutent plein de logs, qu’elles changent le mode de monitoring, etc.

Comment faire en cas de gros changement d’évènement, qui impacte tout le monde ?

Pour discuter avec le conférencier, préférer Twitter.

Question : comment éviter le problème de la complexité de déploiement ?

Question : est-ce que c’est adapté à un éditeur de logiciels ? En particulier pour les clients qui ont le service installé chez eux, donc il faut vraiment qu’on passe en mode Cloud.

Question : à quoi servait le RSS du service ? A réaliser un mode complètement asynchrone sans avoir la complexité d’un bus. Chaque émet son besoin dans son RSS et les autres écoutent et traitent ce qu’ils savent faire.

Question : est-ce qu’il y a une cartographie ? Broadcast de messages OPTION pour que chaque service réponde avec la liste de ce qu’il fait faire.

Concevoir en équipe sans architecte

Peu de notes sur cette session, pour la raison que je suis personnellement en désaccord avec le contenu. Pour moi, l’orateur a confondu deux réalités distinctes : le rôle de l’architecte n’est pas de concevoir. La conception est faite par les développeurs, effectivement. Mais l’architecte est nécessaire lorsque plusieurs équipes ont besoin de communiquer et que des normes n’existent pas encore.

Bref, approche réductrice et volontairement polémique, qui ne fait pas avancer les choses. Bien sûr qu’on peut développer sans architecte. Mais pas tout. De la même manière que pour faire ma vidange, je n’ai pas besoin d’un mécano. Mais s’il faut déposer le moteur, je préfère le laisser faire.

Leap Motion en Java / Processing (Claude Falguière)

Processing + Hermes (game engine) + Leap Motion

setup / draw : les deux fonctions de base pour Processing

Processing gère le changement de référentiel, pratique car Leap part du bas alors que Processing est en bas. pushMatrix / translate / popMatrix pour réaliser ceci.

rdlester.github.io/hermes pour bien comprendre par le jeu. Hermes possède un moteur physique, gère la propagation des évènements pour ne pas avoir une méthode draw trop complexe dans Processing. Il y a aussi du MVC dans Hermes. Les objets visuels sont des vues, et le World est le controleur.

World gère le thread graphique et le rendu concurrent. Les Being sont les objets, les Groupes permettent d’assembler les Being (par exemple le groupe de briques dans le jeu de casse-brique qui est notre exemple). Les Interactor et les Collider sont les objets pour la gestion physique, avec les bounding box. Enfin, PostOffice est un gestionnaire de messages entre objets. La difficulté est de propager les évènements en fonction des stades de l’objet, et plutôt que d’appeler toutes les méthodes, on peut faire avec ce mode du publish / subscribe.

Hermes.setPApplet(this); // Hermes a besoin de connaître le contexte graphique de Processing

Update permet de faire les calculs avant que draw ne soit appelé, de façon à réduire le lag. On peut aussi utiliser PreUpdate, par exemple pour récupérer les données de la Leap.

Pour intégrer Leap Motion, on utilise des commandes de type OSC (envoie des tableaux, au lieu de Keys ou de positions de souris).

import de.voidplus.leapmotion.*; pour ramener tous les objets API de LeapMotion par une librairie spéciale et existante pour Processing.

leap = new LeapMotion(Hermes.getPApplet());

https://github.io/cfalguiere/Air-Breakout et http://cfalguiere.github.io/Presentations

Penser à updater le driver, car il est plus précis désormais (détection de phalanges, etc.)

Au final, super session, bien entre les deux entre les explications de haut niveau et le technique. Je me pose la question : serait-il possible d’utiliser Leap pour piloter Maya ?

Vagrant pour les développeurs (Alexis Seigneurin)

Sert à l’orchestration de machines virtuelles. Ne fait pas la virtualisation. C’est Virtual Box, par exemple, qui fait ceci. Vagrant s’occupe de configurer la Base Box (l’image nue de l’OS) et d’installer dessus les programmes et fichiers qu’on lui demande (c’est le Vagrant file).

Le but est de reproduire de la production sur les machines de développeurs, même si c’est aussi utilisé pour déployer des machines en production.

Vagrant crée la Virtual Box / VMWare / HyperV, configure le réseau, les répertoires partagés, et fait le provisionning (shell, Puppet, Chef, etc.)

vagrantcloud.com et cloud-images.ubuntu.com/vagrant pour récupérer des base boxes (mais attention aux images pas officielles)

Les base boxes sont mises en cache local, pour ne pas les télécharger à chaque fois. Pour cela, on crée un alias qui s’appelle box. Dans provision.sh, pas besoin de sudo, mais ne pas oublier d’enlever le mode interactif (enlever les demandes de confirmation).

vagrant up démarre la box, et quand SSH est prêt, a fait la configuration et le provisionning.

vagrant ssh permet de se loguer sur la machine virtuelle, avec la clé SSH que vagrant a positionnée.

vagrant status renvoie l’état de la machine.

vagrant provision relance le provisionning, pour installer plus de choses. Le script est alors relancé en root sur la machine virtuelle, et le retour de la console est renvoyé sur le shell depuis lequel on manipule Vagrant.

vagrant suspend permet de ne pas avoir à passer par l’interface de Virtual Box, et fonctionnerait pareil avec VMWare.

vagrant destroy pour supprimer la machine.

Infrastructure avec un Nginx en load balancer et deux Apache derrière, avec une configuration réseau posée statique.

On peut avoir du forward de port dans le fichier de configuration, la définition d’un fichier de provisionning partagé par toutes les machines.

Si on fait un vagrant up avec un nom derrière, ça démarre cette machine-là.

vagrant status, dans ce cas, donne les différents statuts pour toutes les machines.

Refaire l’exercice sous forme de session du midi en faisant voir que quand une machine tombe, après le timeout, on vient bien dessus grâce au round robbin de Nginx.

Le repackaging de box permet de créer ses propres base boxes avec des choses installées dessus. On fait pour cela un snapshot qu’on pourra redistribuer.

vagrant box list donne toutes les boxes de base qui existent sur la machine (pas les machines virtuelles, les boxes de base qui servent à monter des machines).

VBoxManage list vms donne la liste des machines qui tournent.

vagrant package –base [id de la machine] –ouput [fichier] permet de créer un package empreinte dont on pourra se servir comme base pour d’autres création automatique. Il fait un tar du vmdk et d’autres fichiers nécessaires.

vagrant box add [nom] [fichier] pour ajouter le fichier ainsi généré comme nouvelle base box (on pourrait l’envoyer sur internet dans un repo, si on ne souhaite pas rester en local).

Outil Packer plus complexe, mais qui permet d’avoir le contrôle sur une ISO originale et de donner un fichier de preceding qui donne toutes les réponses qui doivent être données pour l’install interactive.

http://github.com/aseigneurin/pres-vagrant-breizhcamp

http://aseigneurin.github.io/pres-vagrant-breizhcamp

Keynote jour 2

Startup vs SSII

How to scale your app (Quentin Adam)

Opposition scale up / scale out : grossir une instance, ce qui ne tient pas à long terme, ou découper.

Première chose : séparer clairement code et data. La clé est le « sans état » : une machine ne sait absolument rien de la data. Elle est remplaçable. D’ailleurs, on ne doit pas lui donner un nom, mais plutôt un numéro. Les sessions sont de la data. Un event est de la donnée : on doit passer par une queue, un disque dur, une base de donnée, etc.

Du coup, il faut absolument un middleware, qui donne du trust.

RabbitMQ testé par le Comité Interbancaire Américain. C’est fait pour qu’on puisse avoir une confiance absolue dans la livraison du message.

Tout le processus de data en INSERT pur est en fait une simple queue. On revient sur les principes de performance liés à la prévalence objet : un moteur super rapide en écriture, dans lequel on évite les problèmes de lock grâce à la rapidité, qui permet de traiter les requêtes les unes après les autres + plusieurs instances repliquées en asynchrone (mode CQRS) pour la lecture des données et le reporting avec des agrégations spécifiques.

Pour le datastore, il est une bonne idée d’avoir plusieurs types. Comme ça, on peut adapter en fonction de si on a besoin de l’ACID ou pas, si on a besoin d’accès concurrent en lecture / écriture, si on a plus d’écriture (logs, etc.) ou plus de lecture, si on a besoin de relations (et dans ce cas, pas de MongoDB), si on a besoin de grosses capacités (et dans ce cas, pas de RAM-based)

Amazon Web Services a 6 jours de down time par an, ce qui est loin d’être faible.

Utiliser des bases de données en ligne empêche de se bloquer pour des questions d’install, et force à coder correctement le client pour qu’il reste réactif. Si l’admin n’est pas capable de gérer cette nouvelle techno, il faut que ce soit pris comme un service en ligne.

Ne jamais utiliser le filesystem local des serveurs : POSIX est ACID et ne peut donc pas scaler. Il y a plein de solutions (S3, etc.) mais ne pas utiliser GridFS de MongoDB car c’est un hack sur le FS local, et qui perd des fichiers. Les logs ne doivent pas être stockés sur des fichiers : ils doivent être envoyés dans syslog / logstash.

Conseil : utiliser le streaming d’IO pour envoyer directement la data dans la DB.

Ne pas utiliser la mémoire comme une base de données : ne pas mettre la connexion DB dans la session, ne pas faire de variables globales, ne pas faire de cache dans le code, etc. La RAM doit être complètement stateless. La vie d’une variable doit être limitée à une seule requête, de la même manière qu’une salle d’opérations doit être complètement nettoyée avant la prochaine intervention chirurgicale. On rejoint le concept de programmation fonctionnelle : une requête, c’est une fonction mathématique : entrée donne sortie, et point.

Pompage.net : « Comment j’ai expliqué REST à ma femme » explique l’importance de respecter HTTP. On pourra beaucoup plus scaler si tout le monde comprend ce que fait l’application. Exemple : si l’admin sait que c’est un GET, il paramétrera un Varnish, et roule.

Le code peut planter, et il le fera toujours. C’est pour ça qu’il faut séparer la donnée et ne pas la mettre en mémoire pour ne pas qu’elle soit perdue à ce moment-là.

Ne pas utiliser de framework qu’on ne comprend pas. Exemple de Angular.JS qui parse le code avec des expressions régulières pour offrir des fonctions de réflexion. Si ça paraît magique, c’est certainement qu’il y a un truc pourri derrière. Exemple de MeteorJS qui a besoin de sticky sessions et pourrit donc les cookies.

Conseil final : bien utiliser l’outil qui convient à votre projet et ne pas laisser des geeks venir avec la dernière techno à la mode sans connaître le but du projet.

Dans la boîte de l’orateur, une pratique est d’empêcher le code de grossir, pour ne pas créer des monstres. Il faut savoir bouger d’un langage à l’autre.

Toutes les hard computations sont en Async. Les calculs complexes sont faits en dehors du traitement de la requête. La requête elle-même doit aller vite. Ce calcul peut même être fait avec un autre langage, et le séparer rend aussi plus simple de comprendre qu’un applicatif dédié va lentement, pendant que tout le reste va à une vitesse normale. Le superviseur Nagios ne verra pas ainsi un mélange de temps de requête qui est « normal » car certaines font des calculs.

Faire des modules spécialisés qui vont vite. C’est le retour de SOA, mais sans le dire. Ca permet de bien séparer les équipes. C’est ce qui permet d’avoir des équipes internationales. Chacun s’occupe de son micro-service. Cela permet d’utiliser la puissance du rewrite everything. Le boulot est de bien comprendre le problème, et de réécrire le legacy de manière progressive, en commençant par ce qui pose le plus de souci.

Il est essentiel pour avancer dans ce sens d’avoir industrialisé le process de déploiement. Git push devrait suffire à déclencher toute la ligne.

Toujours utiliser un reverse proxy en frontal. Comme ça, quand il y a un problème sur l’application, on peut toujours faire autre chose, rediriger, mettre un message en attendant, etc. Il faut donc toujours mettre un reverse proxy.

Ne pas s’embêter avec des annuaires de service, alors que DNS fait ça très bien (il y a beaucoup plus de choses que la simple correspondance nom / IP, comme l’envoi d’adresses multiples, etc.)

Enfin, il est essentiel d’avoir dès le début des métriques et des logs. On peut même faire ça sur des services en ligne qui sont capables de gérer ceci.

@waxzce est le Twitter du conférencier

Faire de la veille sur le langage RUST

Le monitoring à l’heure de Devops et Big Data (Claude Falguière)

On passe de la surveillance à l’anticipation et à l’orientation « data »

Le slogan « Measure everything » ne signifie pas de mesurer tout et n’importe quoi, mais de prendre des indicateurs de différents domaines pour ne pas observer un problème d’un seul point de vue.

Intéressant de poser les choses à mesurer dès la construction de la backlog pour recueillir les besoins de tous autour de la donnée enregistrée.

Une application « qui marche bien » : le critère est en termes de service rendu à l’utilisateur, plutôt que des mesures formelles de performance d’un seul service, par exemple. Pour les opérationnels, c’est encore autre chose : plutôt une capacité en ressources. Au final, le SLA est aussi une gestion de risque. Une perte de performance, même forte, peut parfois être tolérée, alors qu’un arrêt définitif serait catastrophique.

Les différents stades :

  • Nombre + unité = mesure
  • Mesure + contexte = métrique
  • Métrique + range = indicateur
  • Indicateur + description = information
  • Information + lecteur = compréhension
  • Compréhension + expérience = connaissance

Bien penser à mesurer les ressources physiques (CPU, RAM, HD, BP), mais aussi configurables (pools, queues, caches, etc.)

Chercher aussi à comprendre le parcours de l’utilisateur, pour améliorer la compréhension du processus global de l’application qu’on cherche à monitorer.

Pour l’urbanisation, intéressant de se poser la question si la signature standard des logs doit bien être un WADL fixe ou bien s’il faut standardiser autour des APIs de style Log4J ou Log4Net, sachant qu’elles ont la possibilité de pousser dans logstash. Au final, tant qu’on fournit une API avec un bon niveau d’indirection, on pourra changer facilement.

Quand on fait des prévisions, il faut déterminer une baseline, et certains outils sont capables de séparer la tendance du cycle.

On peut faire aussi du Complex Event Processing, qui converge avec les outils d’analyse de type Big Data. Par exemple, trois warnings proches sur des modules séparés révèlent un problème réel. Ou bien plusieurs instances qui tombent à quelques minutes d’écart.

Le nb de processeurs en attente est mieux corrélé au nombre de requêtes traités que le taux de CPU, car celui-ci est limité à 100%.

Bonne pratique de mettre dans un dashboard un lien sur la prochaine activité à réaliser. Par exemple, pour ouvrir un ticket d’assistance dans le cas où une mesure n’est pas bonne.

Ne pas oublier de valider le monitoring en termes de représentativité, de fiabilité et de cohérence, de compréhension par le destinataire (exemple des messages incompréhensibles par des personnes autres que le développeur qui les a créés) et d’adaptation de la réponse au problème levé (même si c’est une étape suivante).

Attention à ne pas créer de la contention par le compteur. On peut sharder un compteur.

Ne pas gérer l’alerte directement dans le code, sinon on ne pourra pas gérer les agrégations, l’escalade, le débrayage d’alerte (lorsque le traitement est en cours), l’abonnement sur un média donné, etc. Tout ceci est la responsabilité du système d’alerte, pas de l’application.

Voir Splunk, en parallèle de logstash + elasticsearch

Il faut gérer la collecte / historisation à part, typiquement avec Graphite.

Datomic : base clojure d’insertions seulement.

Jamon, AppDynamic pour le profiling au sens analyse.

Conclusion :

  • Design for failure
  • Identifiez les user stories de monitoring
  • Confrontez vos mesures à la réalité

Java en 15 minutes et en caleçon (Nicolas De Loof)

Blindé de monde, pas pu voir la session. Logique, tout le monde voulait voir Nico en caleçon. Il va vraiment falloir que j’apprenne à être plus vendeur dans mes titres de session Sourire

Sensors en HTML 5

API HTML5 pour accéder à de nombreux capteurs. Certains ne sont pas encore standards, mais il y en a désormais pas mal dans la norme.

Travailler en indépendant (Guillaume Collic)

Airpair.com : des outils pour travailler en pair programming, par exemple modifier le même fichier en même temps, etc.

Nouveautés de MongoDB 2.6 (Tugdual Grall)

@tgrall pour le compte Twitter du conférencier

Améliorations du moteur de requête

Intersection d’index

On ne fait plus appel au GetLastError

Les index peuvent désormais être composés (plus obligé d’avoir un index pour chaque requête qui a besoin), même si c’est limité à deux pour l’instant.

L’agregation framework a suffisamment évolué pour ne plus avoir de raison de passer par le Map Reduce. Il vaut mieux la première solution car elle est beaucoup plus intégrée, sur les mêmes threads, etc. Le Map Reduce nécessite de monter un moteur V8, donc il ne faut le faire que si les opérations deviennent trop complexes pour être réalisées dans le moteur d’agrégation. Jusqu’à la 2.4, l’agrégation se faisait sur un document, et ne pouvait donc pas dépasser 16 Mo. Désormais, dans la 2.6, chaque document répond avec un curseur et on utilise le $out pour le garder dans une collection. Cela permet également d’avoir un recalcul uniquement sur ce qui change, et donc de travailler en incrémental.

On peut aussi faire des opérations sur les tableaux dans l’agrégation, ce qui n’était pas possible avant.

Une première version du Full Text Search existait dans la 2.4, mais dans une commande à part. En 2.6, c’est supporté comme un opérateur standard, dans le find ou l’agrégation framework. La fonctionnalité gère le langage : suppression des mots, liens entre les synonymes, etc. Il y a du field-weighted scoring (typiquement, le titre a un poids double par rapport à la recherche sur le contenu d’un blog).

.explain() ou .explain(true) pour avoir des détails sur l’exécution du find.

.agregate( $unwind : « $champ »), $groups, $sum, $out [pour écrire dans une collection]

Sécurité

Rôle dédié en lecteur seule pour la BI et le reporting

$redact pour filtrer au niveau document. On peut utiliser les rôles mais aussi le document lui-même pour affecter les permissions.

Bizarre car se base sur le contenu de tags, mais sans qu’on force l’application du filtre. A voir dans la doc, car pas clair…

Recherche full text

.ensureIndex ( content : « text » )

.find( { $text : { $search : « coucou » } }) ;

Voir aussi la doc, car pas clair sur l’utilisation multi-lingue : les exemples montrent « english » au lieu de « en » qui est la norme, donc dur à comprendre comment il s’en tire.

Performance et scalabilité

Possibilité de créer les index en background, sur un nœud secondaire, ce qui permet de ne pas trop gêner la production

Cryptage entre tous les nœuds de la base de données séparé du cryptage en direction du client (le support du SSL est valable pour la version Entreprise). Attention, seuls des produits partenaires permettent d’encrypter les données sur disque.

Il y a des sondes SNMP additionnelles.

Automatisation MMS

Outils pour les administrateurs

Disponible gratuitement en ligne pour monitorer / sauvegarder, et il faut être client support pour pouvoir l’installer localement

Souvent, la sauvegarde est faite par un snapshot des disques. On peut aussi faire un dump, mais c’est lourd. Et sinon, il y a MMS qui va faire une sauvegarde plus à chaud. Ce dernier est disponible en ligne.

Il y a des améliorations de la méthode d’upgrade, par de l’automatisation.

UX Design Thinking (Cédric Bourré)

Conception centré utilisateur : démarche

UX : tout ce qui concerne la compréhension de l’utilisateur, mais aussi du business, et qui est nécessaire avant d’arriver enfin à l’UI

Fonctionnel < robuste < utilisable < pratique < agréable < signifiant : un peu la pyramide de Maslow pour l’expérience. C’est autour du « pratique » que les entreprises s’arrêtent comme la frontière de leur approche.

Qualité d’utilisation = efficience (est-ce que j’ai réussi) + efficacité (est-ce que c’était facile) + satisfaction (est-ce que c’était agréable) + apprentissage (est-ce que la prochaine fois sera plus simple)

Risque d’une conception « technique » : rejet + inadaptation (donc besoin de formation) + déception + sous-performance (perte de temps, typiquement)

Peut-être pas une bonne idée d’avoir un designer attitré, car tout le monde doit être impliqué : les fonctionnels, les utilisateurs, etc.

Les 5 étapes de méthode de conception Design Thinking : comprendre le besoin, puis concepts / idéation, puis interaction, puis tester et adapter, et enfin atteindre le produit fini

Socialcompare.com

Argument de ROI : ergonomie mal pensée fait perdre une minute par jour pour 1000 employés => 500 jours/an perdus

Mutualiser du code natif multiplateforme (Guillaume Collic)

La part des applications natives par rapport à l’utilisation web des smartphone augmente, et est très forte (80% en 2013, 86% en 2014)

La note de l’application Facebook est passée de 1 à 5 en devenant native

Add shared project reference pour partager au niveau du code source (mais il faut alors avoir des directives de pré-compilation, y compris dans les tests) / Portable Class Libraries pour partager au niveau de la librairie (et compléter avec de l’injection de dépendance)

Danrigby.com

Genymotion : émulateur Android plus performant que celui de base, et gratuit pour usage non commercial

Installer l’application store Xamarin avec son compte pour avoir un tee-shirt

Attention, Xamarin ne cible pas Windows Phone

Soyez productifs avec MEAN (Tugdual Grall)

MEAN = MongoDB / Mongoose / Express / AngularJS / NodeJS

Express = framework de routage de requête HTTP

L’objet JSON est traité dans le même format dans toutes les couches, ce qui permet d’aller très vite pour le développement

Mongoose = framework d’accès à la base de données, même si on peut aussi prendre le plugin NodeJS d’accès direct à la base Mongo

Mongoose possède un schéma de la data structure, une connexion à la base de données (qui utilise le driver Node), le modèle et un moteur de validation

npm mongoose.validation pour plus de fonctionnalités de validation

sudo npm install -g meanio (installation de la stack MEAN)

mean init [nom de l’application]

Cela crée un squelette complet d’application, avec le serverjs, des routes, la configuration, des dépendances de base, etc.

Ligne de commande npm install pour charger toutes les dépendances

Ligne de commande grunt pour lancer l’application

PassportJS est le framework d’authentification

mean user permet de gérer les utilisateurs et de leur ajouter des rôles, par exemple

Mongoose permet de faire de la simili-jointure

Le mapping de Mongoose permet d’éviter que le client envoie n’importe quoi dans le schéma

mean install mean-tokens, puis redémarrage avec grunt : permet de passer l’interface en mode edit l’interface, et de tout modifier directement depuis l’interface elle-même, en multilangue (encore plus puissant qu’avec Liferay)

mean package permet de créer son propre package, comme on en a ajouté un à l’instant (plus pratique que l’ancienne version uniquement avec yeoman)

Le schéma n’empêche pas de rajouter ses propres attributs

Jsonstudio.com

Posted in Retours | Tagged | Leave a comment

Modélisation des outils du Kanban

En écoutant la conférence de Laurent Morrisseau l’an passé à l’Agile Tour Nantes, il m’était venu à l’idée qu’on pourrait modéliser les outils utilisés pour le Kanban. Après un premier jet sorti il y a longtemps, voici donc une première approche publiée, de façon à recueillir des avis.

Les critères selon lesquels on peut établir le système sont :

  • La capacité à être déplacé facilement
  • La capacité à emporter du texte
  • La capacité à laisser modifier ce texte (quitte à ne le faire qu’en ajout)
  • La capacité à véhiculer une couleur

Selon ces critères, on peut noter les différents outils :

  • Post-it : facilement déplaçable, texte modifiable en mode ajout seulement, couleur fixe
  • Les aimants : déplaçable, pas de texte, facilité de changer de couleur (en échangeant les aimants)
  • Les fiches aimantées : déplaçables, texte modifiable, couleur fixe
  • Les Post-it géants sur lesquels on peut mettre des Post-it standards : comme les Post-it standards, sauf qu’en plus d’être facilement déplaçables, ils permettent de déplacer des ensembles de Post-it d’un coup (un ersatz du couper/coller qui nous manque tant quand on restructure un Kanban)

Le but de ce système : faciliter l’alignement entre les valeurs que vous souhaitez représenter dans un Kanban et les outils qu’il faudra utiliser pour. Si vous êtes sur un Kanban à niveau très fin comme des tâches à la journée, voire à l’heure, il y a de bonnes chances que le texte ne change que peu, et les post-its sont idéaux. Si vous avez des tâches à plus long terme (plutôt orienté planning), les bandes aimantées seront plus pratiques. Si vous avez des tâches sur lesquelles un rôle change souvent de personne, vous aurez intérêt à utiliser des aimants plutôt que d’écrire sur le post-it, etc.

Posted in Agile, Méthodologie | Tagged | Leave a comment

Quelques livres essentiels pour un informaticien

C’est la mode sur internet de faire des listes avec “les 10 meilleurs blogs d’info” ou “6 raisons de programmer en Python”, etc. Du coup, je m’y mets aussi avec une liste toute personnelle de livres “fondateurs”. Il s’agit des quelques livres que je considère comme les plus influents sur mon mode de pensée. Ceux qui ont modifié ma perception du métier. Bien sûr, ça s’applique à ma façon de penser, et ça n’a rien de général, mais je pensais que ça valait le coup de faire cette liste, ne serait-ce que pour mettre en avant ces livres qui le méritent bien.

La liste est bien pour un informaticien au sens large, et pas pour de la programmation. En fait, les livres techniques marquent rarement l’esprit. Ils peuvent bien sûr être de très grande qualité, mais leur utilité n’est qu’en réponse à des questions qu’on se pose. Les grands livres sont ceux qui font qu’on se pose des questions auxquelles nous n’avions jamais pensé avant. Et ce sont souvent des livres sur la méthodologie, l’architecture, les bonnes pratiques.

Clean Code (Robert Martin)

A tout seigneur, tout honneur. Si vous n’aimez pas lire, et que vous êtes d’accord pour faire l’effort à condition d’apprendre énormément, mais en un seul bouquin, c’est celui-ci qu’il faut lire.

Clean Code, comme son nom l’indique, vous apprend tout simplement à coder proprement.

Je suis souvent surpris par les cours de POO qui mettent l’accent sur l’héritage alors qu’on ne s’en sert finalement que très peu, et laissent de côté les interfaces, alors que c’est la base de n’importe quel code correctement architecturé. Ce livre nous apprend comment bien utiliser les interfaces pour assouplir le code, comment nommer proprement les variables, comment gérer correctement les erreurs, etc.

En fait, n’importe quelle personne qui programme devrait avoir lu “Clean Code” avant de livrer le moindre bout de ligne en production.

Le But (Eliyahu Goldratt)

Il semble que ce soit une marque de fabrique des grands livres : ils expliquent des évidences qui ne le sont pas avant qu’on les découvre.

Une des choses qui m’a le plus frappé est la démonstration qu’une usine peut aller plus vite si on laisse à un moment donné des gens ne pas travailler. Ca parait complètement contre-intuitif, voire absurde. Il est possible que quelqu’un qui ne fait rien empêche du coup la production d’augmenter, mais comment le fait qu’il travaille pourrait avoir pour effet de baisser la production totale ? La solution réside dans le fait que notre modèle de la production est trop simple. On pense que ce qui est réalisé sort, mais on ne prend pas en compte les interactions entre les processus, et les goulets d’étranglements.

Le cas d’école est celui d’une machine-outil inutilisée. La patron passe dans les ateliers, met un savon à un ouvrir qui a les bras croisés et lui demande de faire quelque chose. L’ouvrier décide alors de constituer un petit stock de soupapes, pour la prochaine commande. Manque de chance, alors qu’il vient de faire ses réglages d’outils, une autre section de l’atelier n’a plus de stock de cames, et lui en demande. Le voila donc à perdre du temps pour régler la machine, retardant ainsi les autres, et au final potentiellement toute la chaine de production du moteur. Au final, le patron aurait mieux fait de laisser l’ouvrier se reposer pour le prochain rush, ou encore mieux aurait du réfléchir à l’endroit où l’ouvrier aurait pu aider à accélérer un autre processus.

L’auteur explique ça cent fois mieux que moi, et surtout propose des solutions simples et éprouvées (par Toyota en particulier, dans son approche Lean de flux tiré pour réduire les stocks et les gaspillages). En plus de cela, le livre est écrit comme un roman initiatique, se lit très facilement, et explique clairement les principes de Drum Buffer Rope.

Bref, si vous voulez comprendre comment travailler plus peut vous faire perdre de l’argent si vous ne travaillez pas intelligemment, c’est l’ouvrage de référence.

Design Patterns (Gamma, Helm, Johnson & Vlissides)

Qui n’a pas entendu parler du célèbre “Gang of four” ? Ces quatre-là sont à l’origine de la formalisation de la plupart des patterns de programmation objet.

Là encore, c’est une marque des grandes avancées que de fournir des résultats qui paraissent des évidences quand on les lit. La plupart des patterns sont logiques, irréfutables, et on se prend même à se dire qu’on aurait pu les inventer nous-mêmes si besoin. C’est d’ailleurs le propre des patterns de ne pas être une invention à proprement parler, mais une bonne pratique issue de nombreuses personnes sans lien, et qui s’impose comme la bonne façon de faire.

Mais mettre tout ceci dans un seul livre, expliquer leur substantifique moëlle, nommer les choses (une des grandes difficultés en informatique), c’est un énorme travail, et qui sert désormais à des millions d’informaticiens dans le monde.

Entreprise Integration Patterns (Hohpe & Woolf)

Ce livre est la bible des urbanistes et architectes logiciels. Il pose les fondements de l’architecture de médiation nécessaire à garder des systèmes d’information souples.

Surtout, ce livre est à l’origine d’un véritable standard de fait, car les EIP présentés sont devenues la référence des atomes de composition des routes de médiation et d’orchestration dans les middleware orientés messages.

Si vous êtes amenés à faire interopérer des systèmes informatiques, et que vous n’avez le temps de lire qu’un seul livre, c’est celui-ci qu’il faut lire. Pas nécessairement en entier, mais comprendre tous les patterns est un apport énorme. Les explications sont extrêmement détaillées sur chaque, mais une première lecture peut tout-à-fait être réalisée en se bornant à comprendre le principe de chaque pattern. Le livre sera ensuite une ressource précieuse lors de l’application d’un pattern en particulier pour connaitre ses caractéristiques, mieux comprendre comment le mettre en œuvre, les pièges associés dans lesquels vous tomberez forcément si vous ne vous documentez pas, etc.

Writing SOLID code (Maguire)

Une fois que vous connaitrez les patterns de programmation orientée objet, vous vous rendrez certainement compte qu’il émerge une sorte de “meta-pattern” de programmation consistant à utiliser les interfaces comme des contrats permettant de développer des blocs plus autonomes, sous forme de composants.

Cette approche est formalisée dans cinq grands principes qui sont le principe de responsabilité unique (S pour Single Responsibility), le principe Ouvert / Fermé (O pour Open/Closed), le principe de substitution de Liskov (L), le principe de ségrégation d’interface (I) et le principe d’inversion de dépendance (D).

Ce livre pose ces principes et les détaille en profondeur, en expliquant comment ils sont utilisés ensemble pour parvenir à une architecture souple.

SOLID a souvent été appelée “POO made right”. Personnellement, je suis assez d’accord avec le fait qu’on ne devrait pas faire de programmation orientée objet sans connaitre les cinq principes SOLID.

Hard Code (Brechner)

Full disclosure, tout d’abord : je tiens à préciser que je suis le traducteur de cette œuvre en français. Mais ce n’est pas parce que je le traduis que je veux le mettre en avant. Au contraire, justement : je fais l’effort de le traduire parce que je considère que le bouquin le vaut.

Pour l’anecdote, l’éditeur français n’était pas intéressé par une traduction, et j’ai racheté les droits avec mes propres sous pour pouvoir réaliser cette traduction, car ce livre me parait absolument essentiel. Payer pour bosser, c’est un concept nouveau… Comme dirait ma femme : “t’as intérêt à en vendre !” Sourire On verra si c’est le cas, mais même si je n’en vends que quelques-uns à mes proches collègues, je serai satisfait. C’est d’ailleurs une d’entre elles qui a été le déclencheur de la traduction. Considérant que le sujet était essentiel, j’avais fait un petit retour sur quelques heures en interne, en disant à mes collègues à la fin de la présentation que ce serait bien qu’ils lisent le tout. La collègue en question m’a dit qu’elle le ferait si c’était en français. Je l’ai prise au mot…

Mais venons-en au plus important : le livre, et son contenu à la fois riche et déroutant, déjanté, parfois à la limite de la politesse, également controversé, polémique à dessein, parfois extrêmement cérébral mais toujours plein de bon sens.

Eric Brechner a regroupé dans ce livre une centaine de ses plus grands succès dans les articles de blogs qu’il publie en interne à Microsoft depuis une bonne dizaine d’années, sous le pseudo de I.M. Wright (“Monsieur J’ai Raison”). Ses articles sont dérangeants, polémiques. Il n’hésite pas à appeler un chat un chat, et s’il considère que Microsoft ne fait pas bien quelque chose, il le dit tel quel : “nous sommes nuls” (et j’édulcore sévèrement le vocabulaire, bien plus… disons charpenté).

Chaque article surprend le lecteur dès le début, l’interpelle au minimum, voire suscite une réaction épidermique. On a parfois l’impression de se faire alpaguer, puis secouer par le col. Lors de la première lecture de ce livre (j’en suis à la troisième, et j’en apprends encore), combien de fois me suis-je dit “là, il raconte vraiment n’importe quoi”, pour, quelques pages plus tard à peine, me dire que c’était un génie, qu’au contraire, sa conclusion était frappée au coin du bon sens. Eric Brechner nous fait parfois nous sentir idiots : vexés d’être tombés dans le piège qu’il décrit, et encore plus lorsque la solution nous apparait, simple, logique, indiscutable.

J’ai eu l’honneur de rencontrer Eric Brechner en vrai, lors du MVP Summit de Microsoft à Seattle. Il m’a consacré une heure de son emploi du temps de ministre, et rien que dans cette heure, j’ai appris plus qu’en plusieurs formations sur la gestion des équipes informatiques.

Ingénierie et Intégration des Systèmes (Meinadier)

Celui-ci, c’est le prototype du bouquin qu’il vaut mieux ne pas lire avant d’avoir une bonne connaissance du sujet de l’ingénierie informatique. Ce n’est pas un livre qui a été écrit pour introduire, expliquer ou détailler. C’est un bouquin dont le but est de formaliser, de conceptualiser. Bref, compréhensible seulement après au moins cinq ans d’expérience, mais qui vous permet de structurer fortement vos connaissances, de les charpenter et de combler tous les trous dans votre expérience terrain.

Que ce soit sur le maintien en condition opérationnel, la façon théoriquement propre de concevoir des cahier des charges, le bon vocabulaire pour gérer l’intégration de grands systèmes, ce (vieux) livre est une somme. Clairement, il est plus destiné à des architectes, directeurs techniques chez des éditeurs ou directeurs de systèmes informatiques qu’à des programmeurs. Mais il reste une excellente lecture pour ces derniers, une fois experts.

Un grand merci à ce client – d’origine Frioulane comme moi – qui m’a pointé vers cette excellente source.

Domain Driven Design (Evans)

Un autre bouquin très connu, ou en tout cas sur un sujet qui a fait beaucoup de bruit. Ils sont rares ces livres ou ces auteurs qui inventent un pan complet de l’industrie informatique et dont le concept phare devient une façon de faire reconnue comme innovante et largement diffusée. C’est le cas pour ce livre d’Evans qui a posé les bases du Domain-Driven Design, et influé sur de nombreux architectes.

Les liens avec l’agilité ainsi qu’avec les approches CQRS sont aujourd’hui évidents, mais à l’époque de son écriture, ce bouquin avançait sur des concepts complètement nouveaux, et qui allaient à l’encontre des approches traditionnelles de conception et de modélisation.

Le simple fait que la préface soit de Martin Fowler suffisait presque à dire que c’était un bon bouquin, mais à le lire, on sait que c’est le genre de livre qu’on ne revendra pas, et qu’on relira certainement de temps à autre pour continuer à glaner des idées supplémentaires. Un peu comme une bonne BD qu’on relit souvent car on y trouve à chaque fois quelque chose de nouveau.

Effective C# (Wagner)

et

Peut-être pas des livres aussi importants que les précédents, mais quand je faisais la liste dans ma tête des livres qui m’ont réellement marqués, ces deux-ci arrivent juste derrière. Il se peut que ce soit du à un contexte particulier de lecture à l’époque, mais le contenu, bien qu’inégal, n’en est pas moins de très bonne qualité.

Le gros avantage de ce livre est qu’il ne s’adresse qu’à des personnes qui connaissent déjà bien .NET, et ne veulent que découvrir des “gotchas” (des moments “eurêka”, pourrait-on traduire). Du coup, en quelques pages, on apprend beaucoup de choses, alors que dans les bouquins techniques traditionnels, qui reprennent toujours la base, ne serait-ce que rapidement, on se retrouve souvent à aller directement vers les derniers chapitres pour apprendre plus.

Pour ma part, je considère que ce sont ces lectures qui m’ont fait passé du stade de simple programmeur à celui d’informaticien professionnel.

Et en dernier… le vôtre !

En numéro 10, j’aurais pu mettre un des miens, pas pour le mettre en avant en tant que livre, mais pour dire que ce qui vous marquera et vous développera le plus en tant qu’informaticien (et, oserais-je le dire, en tant que personne), c’est bien de vous lancer et d’écrire le vôtre :

  • Rien de mieux que de passer des jours et des heures à chercher comment expliquer un concept de la manière la plus simple possible pour le maitriser complètement.
  • Rien de mieux que de se mettre à écrire pour se rendre compte que, finalement, ce sujet dont on se croyait expert, eh bien il nous reste encore pas mal de recherche et de lecture à réaliser pour vraiment le devenir.
  • Rien de mieux qu’avoir pesté contre une critique d’une personne qui se permet de faire des remarques sur un sujet qui n’était pas celui poursuivi pour apprendre à soi-même être beaucoup plus attentif et précis dans ses propres remarques.

Bonne lecture, et je suis intéressé par toute liste similaire si vous en faites une.

Posted in Retours | Tagged | 2 Comments

Premier cours aux Mines

Après être allé plusieurs fois aux Mines de Nantes pour l’AgileTour, ça fait bizarre d’y aller pour donner un cours. La vue des salles de TD est absolument géniale :

image

Sympa d’avoir une école d’ingénieurs avec les champs et les chevaux en fond. Juste au bord de Nantes, je ne pensais pas tomber en pleine campagne. Très agréable !

Pour le cours lui-même : une journée complète pour expliquer les architectures orientées services. Pour une fois, pas besoin de faire en quelques heures ! Enfin du temps pour bien expliquer les fondations, le pourquoi de ce type d’architecture, etc. Sourire Du coup, toute la théorie le matin, et l’après-midi, mise en application sur un scénario à urbaniser de A à Z, avec utilisation de Bonita BPM pour la modélisation. Pas eu le temps de faire beaucoup de tests avec SOAPUI (le temps passe vite, même avec une journée complète), mais les trois groupes ont réussi à voir à peu près tous les pièges de couplage comportementaux ou temporels qu’il y avait dans ce scénario de demande de bourse étudiante.

Le cours est disponible ici.

Le ROTI donne ceci pour le fond et pour la forme :

image

Content de voir que le cours a plu. Et surtout, un futur architecte a été convaincu Sourire

Posted in Uncategorized | Leave a comment

Mon nouveau livre sur PowerPivot 2013

Il est enfin arrivé Sourire Après une longue gestation, un accouchement pas trop difficile et une reconnaissance émue par son papa (eh oui, pour une fois, c’est la maman qui avait le rôle le plus facile…), voici mon nouveau bouquin sur PowerPivot :

image

Il s’agit d’une grosse réécriture du précédent qui portait sur PowerPivot 2010. Au début, il s’agissait surtout de remettre à jour, mais les nouveaux sujets sont tels que ça s’est fini par beaucoup de changement et surtout de nouveautés : Power Query, Power View, rapports interactifs, cartographies, etc.

C’est en écrivant ce bouquin que je me suis rendu compte à quel point c’était incroyable d’avoir gratuitement un outil de manipulation des données volumineuses aussi complet. Personnellement, j’en viens à me demander pourquoi des gens achètent QlikView ou Tableau, vu que PowerPivot fait tout pareil, voire mieux pour la gestion des relations et pour le chargement des données.

La présentation détaillée et le lien pour acheter sont sur la page dédiée du site ENI.

Posted in Uncategorized | Tagged | Leave a comment

Toujours au plus mauvais moment…

En pleine relecture de mon dernier livre (sur PowerPivot pour Excel 2013), deux jours avant la livraison… boum ! PowerPivot ne fonctionne plus Triste

Erreur : “Invalid Pointer Array”, suivie d’un autre dialogue “PowerPivot ne peut pas charger le modèle de données”.

Pensant que ça vient de l’installation de la nouvelle version 2.10 de PowerQuery que je venais juste de réaliser, je la désactive, puis la désinstalle, puis désactive et réactive le module PowerPivot, puis répare Office, puis déinstalle et réinstalle Excel. Après moultes redémarrages et perte d’une heure, puis recherche sur internet (avec la difficulté de d’abord trouver la bonne traduction anglaise du message en français), il se trouve que c’est une KB d’Octobre 2013, la 2825655, qui met le bazar.

Pourquoi n’ai-je pas eu le problème avant ? Mystère ? La KB était-elle tirée par PowerQuery 2.10 ? Je n’en saurai certainement rien non plus.

La solution : installer le fix KB 2837666, disponible sur http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2837666

D’après ce lien, il semblerait que le problème ait été poussé dans l’Update Windows récent… pile au pire moment !

Posted in Retours | Tagged | 4 Comments

Séminaire ADN Ouest

Très intéressant séminaire ce jour, organisé par ADN Ouest. C’est toujours très intéressant d’avoir des retours d’universitaires, qui nous donne une profondeur de vision qui nous manque parfois, à nous autres industriels qui sommes le nez dans le guidon.

image

Jean Bézivin nous a fait un retour sur 50 ans d’informatique et une prospective sur la même période ! Je me rappelle avoir utilisé l’expression “boule de cristal” pour parler de ma roadmap d’architecture à plus de 2-3 ans, nous ne sommes clairement pas sur les mêmes échelles de temps Sourire. Ce qui est rassurant, c’est de voir que les fondamentaux de l’évolution du métier sont vus par lui de la même manière que ce qu’on constate dans la pratique, à savoir la spécialisation du métier de développeur. Il y aura effectivement de plus en plus de gens qui ont une petite compétence en programmation, mais les développeurs “core” seront moins nombreux et de plus en plus experts.

Philippe Desfrays parle de modélisation en général, et établit la différence entre l’approche UML qui était centralisatrice et les approches de domaines qu’il présente comme l’avenir de la modélisation : BPMN pour le métier, SysML, etc. Pour faire un parallèle avec ce dont je parlais juste avant sur les capacités des développeurs, BPMN me paraît avoir le potentiel d’être un nouvel Excel dans le sens où il peut autoriser des non-développeurs à avoir une activité de développement, sans programmation. Idem pour les BRMS, à condition qu’il s’accompagne d’éditeurs graphiques sympas. Les approches services sont particulièrement indiquées dans ce contexte : le contrat permet de sécuriser l’implémentation, et d’exposer une interface contractuelle aisément utilisable par des spécialistes du métier et non de la technique. C’est ce qui est à l’oeuvre dans Scratch : les actions sont des pièces de puzzle, montrant bien la présence d’un contrat (les formes doivent être correspondantes pour s’imbriquer).

Pour ce qui est des normes et de la modélisation métier, je n’ai pas une vision aussi pessimiste que Philippe Desfrays : XBRL pour les états financiers des banques, ACORD pour les assurances, OTA pour les voyagistes… il y a de nombreuses normes métier utilisables, et il n’est pas utile de réinventer la roue. De plus, de nombreuses entreprises commencent à avoir le réflexe de publier leurs contrats dans des forges pour qu’ils deviennent des standards d’usage (à MGDIS, où je travaille, nous avons commencé). Et pour ce qui est de courir dans les couloirs des banques pour trouver quelles applications sont impactées par une modification règlementaire, il y a les approches de type BCM qui aident bien. J’ai failli répondre positivement lorsque Philippe Desfrays a demandé qui avait une vision centralisée de ses modèles métier, mais nous n’avons pas encore fini notre cartographie, donc restons modeste…

En fait, le vrai problème sur les normes est la maturité. Avec BPMN 2.0, on en enfin quelque chose de propre (après des années de combat entre BPMN 1, WSFL, BPEL4WS, WS-BPEL, WSCL, etc.) et on peut ouvrir un diagramme dans un éditeur après l’avoir créé dans un autre, faire une modification et revenir au premier sans problème. Ce n’est pas la même chose avec XMI où je n’ai jamais réussi à ouvrir un schéma d’un éditeur dans un autre…

Personnellement, je pense que la modélisation au niveau UML était trop haute, et pas agile : elle s’attelait à modéliser la partie logicielle, alors que le bon niveau de conceptualisation est celui du métier du client. De cette manière, on est toujours sûr d’être au plus près de la valeur ajoutée par l’informatique, et d’éviter le mismatch business / software. Ensuite, une fois que la conceptualisation et l’orchestration ont été réalisées, on peut passer à de la modélisation logicielle pour préparer l’implémentation d’un service. Au moins, on travaille sur un domaine restreint, on ne fait pas du Big Design Up Front, et on a moins de risque sur l’approche modèle ne colle pas.

Laurence Duchien expliquait que des méthodes voyaient le jour pour sécuriser les appels des services dans des environnements très hétérogènes. Intéressant de voir que l’académie avance sur des approches de sécurisation côté client. Personnellement, j’ai tendance à dire que, s’il y a risque de défaillance du service, il faut mettre à jour les contraintes non fonctionnelles du contrat de service pour sécuriser le SLA, puis seulement jouer sur le client, mais c’était peut-être l’hypothèse faite par Laurence Duchien et que je n’ai pas nécessairement saisie. Des approches comme les providers ADO.NET pour SQL Azure incorporent d’ores-et-déjà des méthodes de rejeu automatique des commandes annulées pour cause de saute réseau par exemple. Dans les approches Cloud et surtout avec des services de plus en plus distribués, il va y avoir clairement des besoins de plus en plus forts pour ce genre d’APIs à haute résilience.

L’après-midi, toujours un plaisir d’entendre parler d’éco-conception devant un parterre de décideurs. Olivier Philippot s’est montré persuasif et j’espère que certains DSI sont repartis avec l’idée de mettre en œuvre les principes exposés. De simples modifications de code de bon sens peuvent amener à des économies énormes, ça serait dommage de s’en priver.

2014-03-27 14.58.04

J’ai eu le plaisir de présenter en fin de journée une conférence sur l’urbanisation, en apportant en particulier un retour d’expérience sur la mise en place d’une architecture SOA. Difficile de trouver le bon angle quand on intervient devant un public inconnu (je n’avais jamais fait de conférence à ADN Ouest auparavant), mais heureusement les conférences précédentes m’ont aidé à ajuster le discours.

Au final, des rencontres très intéressantes, des questions passionnantes, des orateurs à l’avenant, et en plus un lieu magnifique (le Château de la Poterie, avec même une roulotte – je suis spécialiste Sourire). Bref, une super journée !

2014-03-27 08.26.26

Posted in Uncategorized | Leave a comment

Tech Days 2014 : les sessions sont en ligne

Oui, je sais, j’arrive sérieusement après la bataille, mais j’ai pas mal de boulot en ce moment, entre mon activité professionnelle et un nouveau bouquin en fin de traduction. Du coup, le blog est un peu en jachère, mais vers la fin du printemps, le livre sera sorti, et je vais enfin pouvoir me relancer dans les tests de programmation.

La meilleure session (avec Coding4Fun), c’est ici : http://www.microsoft.com/france/mstechdays/programmes/2014/fiche-session.aspx?ID=41b76c01-5848-4e6a-b453-0fea6b2feaac

La session que j’ai eu le plaisir d’animer avec Jean-Marc Prieur est sur http://www.microsoft.com/france/mstechdays/programmes/2014/fiche-session.aspx?ID=026b038c-9fc1-4ed6-8985-b47dc552dc1f

Ne soyons pas modeste : la session a été très bien reçue, avec un excellent feedback tant pour le contenu (4,5 / 5) que sur les speakers (4,7 / 5) ! Je ne suis pas peu fier de dire que c’est la 9ème la plus appréciée sur un peu moins de 180 sessions Sourire.

Vous avez également un excellent retour de l’ami Guillaume Collic sur son blog : http://guillaumecollic.com/2014/02/techdays2014/

Posted in Retours | Tagged | Leave a comment

TechDays 2014

Cette année, pas de retour session par session comme les années précédentes. Je ne suis pas sûr que c’était plus utile, et ça ne renvoyait pas un sentiment d’ensemble sur l’évènement.

Introduction

L’évènement, donc, ce sont les Microsoft Tech Days de 2014, ce début de Février à Paris. Le plus grand rassemblement informatique en Europe, comme cela a été rappelé lors des deux plénières auxquelles j’ai assisté (je ne suis resté que les deux premiers jours, le premier étant plutôt orienté autour des développeurs, le second autour de l’IT et le troisième pour les « décideurs » (vous savez, ceux qui ne programment plus Sourire).

Un cru en retrait

Pour être tout à fait honnête, je n’ai pas trouvé que ce soit un grand cru. Pour ceux qui en doutent, être MVP ne signifie pas abandonner tout sens critique envers Microsoft, et le feedback, c’est aussi donner le mauvais feedback quand il y en a. Alors, allons-y tout de suite pour ce qu’il y avait de moins bon…

Evidemment, les précautions d’usage sont à prendre : il y a des centaines de sessions, presque une vingtaine par slot, donc je n’ai vu qu’une infime partie de toutes les interventions. Mon avis est personnel, et il faudra donc que vous le croisiez avec d’autres personnes pour vous faire une idée un peu plus rationnelle. Personnellement, c’est ce que j’ai fait avec plusieurs amis présents, et la plupart m’ont conforté dans mes appréciations.

Toutes les années ne peuvent pas être à la conjonction de sorties majeures de produits comme l’a été 2013, par exemple. Il est donc tout à fait normal que les plénières ne laissent pas les gens estomaqués comme certaines autres fois. Normal aussi que les énormes balles (cf. lien) ne soient pas lâchées sur le public ou qu’il n’y ait pas de groupe de rock pour nous accueillir à chaque fois… Ça rend plus appréciable quand cela arrive. Il n’empêche que, comme Eric Vernié, j’ai regretté qu’il n’y ait pas l’enthousiasme d’Eric Mittelette. Nous avons eu le gratin de Microsoft France sur scène pour nous, mais franchement… ils ne m’ont pas fait rêver. La démo la plus top était sur PowerQuery, et pour ce qui était des objets connectés, c’était juste faire faire bip à un badge. On est loin du pilotage d’un robot Lego NXT depuis Robotics Studio, ou d’une démo d’injection SQL en live par Pascal Bellaud !

Je ne m’appesantirai pas sur les problèmes réseaux récurrents qui ont impacté une démo sur deux. Mention tout de même à Stéphanie Hertrich, apparemment la seule à avoir pris ses précautions. Si j’étais méchant, je me permettrai de signaler à Microsoft que, parmi les sponsors de Tech Days, il doit bien se trouver quelques bons spécialistes du réseau capables de régler ça…

Mais bon, tout ceci n’est pas très gênant. On ne peut pas avoir un grand cru toutes les années… Par contre, il y a deux points que, personnellement, j’ai trouvés vraiment négatifs.

Dehors, les charretiers !

En tout premier, le niveau d’expression orale des orateurs est parfois indigent, au point de faire oublier le contenu quand il faut le piocher au détour des hésitations, répétitions, voire grossièretés. Oui, je sais, on est entre techniciens, mais ce n’est pas une raison pour me parler comme si on était au bar entre potes. J’avais même l’impression que certains intervenants extérieurs en rajoutaient, s’imaginant peut-être développer ainsi une connivence avec le public. Leurs accompagnateurs Microsoft faisaient l’effort de s’exprimer correctement, et j’en ai même vu un reprendre l’un des intervenants (merci, David Rousset), mais l’impression était déplorable.

Peut-être que c’est un moyen pour certains de montrer à quel point ils sont cools, détachés du code, tellement bons qu’ils peuvent se permettre de s’exprimer comme des charretiers, leur supériorité technique les plaçant loin au-dessus de la foule. Pour m’être entretenu avec plusieurs d’entre eux en fin de sessions, j’ai souvent observé l’inverse. Les plus suffisants sont en règle générale les moins bons. Une question un peu trop pointue, et la réponse est en générale évasive, voire évacuée comme triviale. Dans le bon sens, j’ai également rencontré des intervenants brillants, et qui n’étaient animés que par le désir de faire passer l’information. En général, ils avaient répété maintes fois leur présentation, qui était parfaitement fluide. Ceux-là sont les premiers à admettre qu’ils n’ont pas toutes les réponses. De mon point de vue, cela ne fait que les grandir. Merci donc aux orateurs, nombreux, qui ont fait cet effort.

Pour les autres… Microsoft, c’est à vous de trier plus en amont. Avez-vous vraiment validé que tous les intervenants extérieurs avaient déjà réalisé des conférences ? Leur avez-vous demandé une vidéo, ou au moins un compte-rendu de ces interventions ? Leur avez-vous envoyé quelques recommandations sur l’expression ? Sur ce point, je peux apporter une réponse, étant moi-même conférencier cette année encore, et celle-ci est négative.

Ce sont les Tech Days, pas une petite conférence de province avec 100 personnes et 10 intervenants ! J’imagine à quel point c’est un énorme travail de préparer tout ça, mais par pitié, triez mieux, quitte à en faire moins. Nous sommes nombreux qui préférerions que les Tech Days restent la meilleure conférence d’Europe plutôt que la plus grande.

Le niveau technique

Le deuxième point négatif (et pour le coup, c’est un show-stopper) est le niveau technique parfois complètement à côté de la plaque. La plaque étant, au choix, le titre, la description de la session, ou même le niveau de l’assistance.

Dans le premier cas, on pourrait dire que le titre n’est qu’une accroche et que seule la description fait foi. Fair enough… Mais pourquoi mettre « urbanisation » dans un titre de session alors qu’à aucun moment on n’y parle d’intégration avec d’autres produits ? Pourquoi parler de « mythes » dans le titre pour n’en démonter absolument aucun pendant la conférence ?

Pour ce qui est des descriptions, outre qu’elles n’étaient parfois pas très descriptives du contenu, elles donnaient dans certains cas des informations erronées sur le niveau visé. Quand on parle de bonnes pratiques ou de retour d’expérience, l’auditoire ne s’attend pas à ce qu’on lui explique la technologie. Il connait déjà, mais veut en savoir plus. Il s’est déjà renseigné en théorie, mais veut savoir comment ça se passe en vrai. Il veut savoir les écueils sur lesquels d’autres ont buté pendant les mois de mise en production, de façon à gagner du temps.

J’imagine bien la solitude de l’intervenant qui, sur sa question sur le nombre de personnes à avoir eu la curiosité de décompresser un package *** (j’anonymise), voit autant de mains se lever dans l’assistance. Mais franchement, comment pouvait-il s’imaginer avoir une salle de débutants aux Tech Days ? Qui plus est le premier jour, dédié aux développeurs ? Ca fait des années que nous utilisons tous plus ou moins cette technologie, nous venons là pour en savoir plus, savoir comment ceux qui en connaissent les rouages la mettent en pratique, quelles sont les astuces de pro, quels problèmes de performance se posent, quelles sont les bonnes pratiques à retenir, les bonnes politiques de nommage, etc. Alors nous faire un cours de programmation qui n’a rien à voir avec le sujet annoncé pendant 30 minutes, et effleurer le sujet principal pendant 15 minutes, désolé, mais ce n’est pas ça du tout qu’on attend.

Qu’on s’entende bien : la session a certainement été intéressante pour les quelques personnes n’ayant jamais touché à Visual Studio. Mais c’est quoi, leur nombre sur l’amphi complet ? 5% ?

Bon, j’arrête

Oui, je sais que j’ai une certaine propension à m’étendre sur les sujets qui m’ont déplus. Mais je n’en suis pas à imaginer sécher les Tech Days. On en ressort toujours avec plein d’idées – qu’on n’a pas toujours le temps de mettre en pratique sur l’année qui reste, mais c’est un autre problème Sourire.

Surtout, il y a des moments de pur bonheur, comme par exemple « C# Async, un an après » où Mitsuru Furuta revient parmi les Microsoftiens pour nous montrer les rouages internes des mécanismes asynchrones de .NET avec une clarté extraordinaire. Incroyable, cette impression de comprendre le pourquoi du comment, alors que deux minutes après la session, on ne serait pas capable de reproduire le même code sans la doc… C’est le signe qu’on a compris quelque chose de profond, pas juste appris une nouvelle méthode ou découvert une classe inconnue auparavant.

Et puis il y a le changement de rythme sur les 45 minutes. Comme pour tout changement vers l’inconnu, la première réaction est de la méfiance, mais il faut bien reconnaitre que ça rend les sessions beaucoup plus rythmées. Impossible de trop s’appesantir sur un sujet, au risque de perdre l’auditoire. Et comme les responsables de salles veillent à ce que le timeboxing soit parfaitement respecté, ça donne un ensemble bien organisé, pas trop de queues entre les sessions, et une journée qui finalement passe vite, peut-être moins fatigante qu’avec des sessions d’une heure (là, c’est une impression 100% subjective et personnelle – c’est peut-être juste que l’hôtel était plus propice au repos).

Pourtant, j’en ai entendus, des gens qui pestaient contre ces 45 minutes, certains même pendant la conférence… Mais au final, c’est un point positif de plus.

Passons à la technique

Pour continuer sur le positif, je vais quand même faire un compte-rendu un peu plus précis de ce que j’ai appris sur ces deux jours, en commençant pas des informations qui ne sont pas limitées à une session. J’entrerai dans le détail de chaque session ensuite.

De manière générale, l’édition m’a parue assez orientée sur la Business Intelligence et les objets connectés. Les concepts de Smart City ont été abordés en plénière, et la part belle a été faite à PowerPivot, Power Query et Power View, ainsi que le petit dernier de la ligne Power BI, à savoir Power Q&A.

Plénière Jour 1

Quelques points marquants de la première plénière (à part l’absence regrettée d’Éric Mittelette)…

Les projets Spark, Siena et AppStudio permettent à des non-développeurs de participer aux non-programmeurs au processus de développement. J’insiste bien sur cette notion de « participation », car les gens du marketing ont vite fait de sauter à la conclusion que Madame Michu va monter de A à Z son propre jeu vidéo demain matin, et faire sauter la banque des téléchargements en un mois, alors que les démonstrations montrent clairement qu’il s’agit simplement d’adaptation sur des bases existantes, mais que les modifications ne se font pas non plus sans un background un peu technique. En bref, ce n’est pas parce qu’on remplace un while dans du code par une icône avec une flèche tournante qu’il ne faut pas avoir compris le concept de boucle.

Toujours dans le domaine des jeux, Microsoft intègre de plus en plus Unity 3D, qui permet de développer des jeux en .NET, WebGL apparaît dans IE 11, et les Microsoftee David Catuhe et David Rousset ont encore frappé fort avec un Framework nommé « BabylonJS » pour faciliter l’exploitation de cette fonctionnalité dans des jeux. On se demande où ils trouvent le temps…

Le TPM inclus dans les tablettes va permettre d’utiliser la possession physique de celles-ci comme un facteur d’authentification (comme si une tablette remplaçait une smartcard).

Un truc tout bête, mais bien dans l’approche traditionnelle de Microsoft de rendre le boulot des développeurs le plus simple possible : la Windows Runtime est disponible en faisant un simple using Windows.* dans son code .NET. Par exemple, using Windows.Media pour accéder à l’API pour prendre une photo. Un développeur un peu curieux aura intérêt à parcourir les différentes classes, de façon à savoir ce qui s’y trouve. Même si on n’a pas de besoins immédiats pour ce genre de fonctionnalités, ça donne des idées.

Dans le même mouvement, la plénière comme d’autres sessions insiste sur les Bing APIs pour la cartographie, la recherche, etc. A ma connaissance, ça existait déjà, mais il a dû y avoir des grosses évolutions pour que le sujet revienne sur le tapis.

Une classe à regarder pour ceux qui s’intéressent au BAM : ClientAnalyticsChannel.

C# Async, un an après

J’en ai parlé un peu plus haut, sur les points les plus positifs de mes retours. Cette session, superbement animée par Mitsuru Furuta (tu as vu, Mitsu, je n’ai pas écrit « Futura » ?) est la meilleure que j’ai suivie. Ça ne ferait pas hommage au contenu de prétendre le résumer dans un compte-rendu, donc je vous renvoie à la vidéo sur le site des Tech Days (elles arrivent en général quelques bonnes semaines après la conférence). De toute façon, il faut voir la progression de code pour bien comprendre ce qui se passe derrière la gestion de l’asynchronisme.

Je me contente donc de remonter quelques informations parcellaires. Par exemple, le fait que tout thread a le droit d’écrire dans la Console.

Ou bien que, de la même façon que la construction using a besoin d’un IDisposable, le mot clé await nécessite un objet qui contienne une méthode GetAwaiter (mais il n’y a pas d’interface pour contractualiser ceci). L’objet renvoyé par cette méthode doit lui-même implémenter INotifyCompletion. Mitsu utilise les méthodes d’extension sur un type simple pour réécrire une gestion de Task minimaliste.

Il nous parle ensuite du CallContext. J’avoue que je ne suis pas très à l’aise avec la notion de contexte dans le multithreading en général, mais il faut savoir que par défaut, lorsqu’on sort d’un thread, on n’a pas de garantie du thread sur lequel on va revenir. La classe Task s’occupe justement de rendre ceci plus facile en utilisant les contextes de synchronisation, bien qu’il soit possible de débrayer ce comportement en utilisant la surcharge ConfigureAwait(false).

ThreadStatic est incompatible avec le thread pooling, et il est donc recommandé d’utilisation CallContext.SetLogicalData si on suit faire suivre une donnée le long d’un contexte d’utilisation. Là encore, je livre l’info un peu brute par manque de compréhension complète. Il faudra quelques essais avec le code pour bien comprendre. Un futur article de blog ?

Pour revenir à la Console, Mitsuru explique que justement, le SynchronizationContext.Current est à null dans ce cas, et il montre ensuite une technique pour créer son propre contexte de synchronisation en héritant SynchronizationContext. Il y a une méchante bidouille qui consiste à créer une feuille Windows de taille nulle, mais apparemment c’est le moyen le plus « standard » de récupérer une pompe à message Windows. C’est le ShowDialog qui fait la boucle d’attente des messages.

Enfin, Mitsuru montre une méthode simple pour chaîner des tâches en séquentiel (typiquement, pour les I/O, ça ne sert à rien de réaliser en parallèle, vu que c’est le disque qui est le goulet d’étranglement). Le code sera sur son blog. Pour ceux qui, comme moi, ne savait pas trop quelle était la bonne méthode pour, sur un cas hypothétique de boucle while d’attente, économiser des cycles d’horloge sans recourir à un arbitraire Thread.Sleep(n ms), une bonne réponse est d’utiliser les ManualResetEvent. Un Reset puis un WaitOne dans la fonction, et un Set pour déclencher. Là encore, il me faudra voir du code et tester pour bien piger le fonctionnement, donc je préfère juste citer la classe et ne pas me risquer à des explications douteuses.

NDepend 5 en action

Intéressant d’avoir le point de vue de Patrick Smacchia, le créateur de cet excellent logiciel, sur ses utilisations possibles. Mais plus encore, c’est un bon exemple du niveau de qualité atteint lorsqu’on fait l’effort de bien tester son produit. Patrick a montré l’évolution impressionnante des tests unitaires de NDepend, et son dog fooding, NDepend étant suivi et « noté » par lui-même. Jusqu’à 80% de couverture par les tests, et une approche très intéressante pour les tests d’intégration : peu de tests, mais sur des scénarios très complets, et surtout du code bourré d’assertions pour traquer tous les problèmes possibles avant qu’ils éclatent en bug. C’est du Code Contract, mais light.

Patrick met sur le même plan les Code Contract et les tests unitaires, dans le sens où chaque technique fait des assertions remontées lors de l’exécution, et qu’il faut corriger. Très pertinent, je trouve, et pour trouver de telles correspondances, il faut bien comprendre en profondeur ce qu’on fait.

Une autre preuve de cette maitrise conceptuelle est la réflexion sur la couverture de code. Pour Patrick, c’est, encore plus qu’une marque de qualité de l’existant, une assurance de pouvoir faire rapidement évoluer le logiciel. Du coup, le ROI n’est pas réellement sur le fait que le support est moins sollicité, mais plutôt sur le fait que NDepend pourra rapidement donner de la valeur ajoutée supplémentaire à ses clients. Ceci est corroboré par l’évolution extrêmement rapide du produit qui en quelques années a mis en place un nombre extraordinaire de fonctionnalités intéressantes.

J’ai également compris dans cette session qu’en plus d’utiliser NDepend pour faire des audits de qualité de code, je pouvais m’en servir pour faire de l’analyse rapide d’une base de code legacy. Bon à savoir, dans des contextes de réécriture, pour savoir ce qui doit être réutilisé et ce qui doit être refondu.

La data n’a pas besoin d’être “big” pour générer de la valeur

Approche intéressante, avec une universitaire présente qui donnera une vraie valeur théorique à la session. Vu que ça fait plusieurs années que j’évangélise mes clients et mes étudiants sur des approches light de la BI, je ne peux pas être plus d’accord avec le titre.

La cartographie des méthodes liées à l’analyse de données par Swami Chandrasekaran donne une idée de la difficulté du choix, avant même de commencer la mise en œuvre.

Pour résumer rapidement, les choix expliqués par cette session étaient sur le remplacement d’une approche Big Data par le mélange de techniques suivantes :

  • Statistiques pour déterminer les critères
  • Algorithmes génétiques pour sélectionner les critères les plus pertinents
  • Réseaux neuronaux pour calculer la corrélation entre les critères et les résultats analysés

En fond, le but était de trouver l’influence de critères de fabrication d’un produit sur l’opinion générale des consommateurs dudit produit après sa phase de fabrication.

Bref, session intéressante. On aurait pu remplacer la désormais traditionnelle explication des 3+1 V de Big Data par une rapide explication des technos utilisées pour coder les réseaux neuronaux et les algos génétiques (Framework ? Open Source ?) ainsi que l’interface WPF très sympa, mais c’est plus un souhait qu’un reproche. Au final, c’est une bonne démonstration qu’effectivement, il n’est pas utile de faire du Big Data pour tirer de l’information intéressante des données. L’approche reste sophistiquée, mais évite le recours à des ressources phénoménales, tout en atteignant des résultats aussi probants, voire plus.

Tour d’horizon de Node.js

Session prise d’assaut, impossible d’entrer malgré que ce soit dans un amphi et que je sois arrivé un quart d’heure à l’avance. Dommage… A suivre sur le site quand les vidéos seront sorties.

Cloud Azure – Service de données et bonnes pratiques

Du coup, je me rabats sur cette session, censée apporter des bonnes pratiques. En fait, il y en aura relativement peu. La session passe pas mal de temps à expliquer les différences entre les tables, les blobs, les queues, SQL Azure et SQL Server sur IaaS Azure, ce qui est très bien pour les débutants. Je résume, donc :

  • Les blobs sont orientés fichiers et supportent les métadonnées. Ils sont faits pour stocker les assets, les images virtuelles, les sauvegardes, etc.
  • Les tables sont des dépôts typés NoSQL, orientés entités, et schemaless.
  • Les queues sont des files de messages, fonctionnent en FIFO, sont limitées à 64 Ko par message et 7 jours de TTL max.
  • SQL Azure est une base de données en SaaS, coûte moins cher qu’un SQL Serveur sur la même machine (surtout qu’il n’y a pas à la gérer), mais a des performances non prédictibles – sauf en mode Premium.
  • SQL Server sur IaaS consiste à gérer son propre SQL Server sur une machine virtuelle Azure. La bonne pratique : tous les disques durs sur le même compte de stockage, mais dans des drives différents (2 par core).

Dataviz & BigData : Mythes & réalités

Là encore, intervention d’un universitaire (Jean-Daniel Fekete, INRIA), ce qui est une bonne idée car, même si le plan n’était pas très carré, le contenu était extrêmement intéressant.

Pour rappel, Data < Information < Connaissance < Sagesse.

Après un rappel sur le fait que la vision soit le sens avec la plus grande bande passante, explication du principe de congruence, à savoir la traduction directe de la donnée en représentation visuelle (par exemple, hauteur d’une colonne dans un graphique reliée à une taille de population).

Démo super intéressante sur l’affichage de données sur plus de 3 dimensions, en utilisant le mouvement d’un cube pour faire ressentir la profondeur, dont l’axe change en fonction de la dimension à représenter. Difficile à décrire avec des mots, mais un graphique en 2D montre deux dimensions, et lorsqu’on en choisit une troisième, elle se place en profondeur (donc, non visible dans un premier temps), puis le cube tourne et remplace une des deux autres dimensions. La sélection de groupes rémanente permet de suivre les entités plus facilement. Pour avoir réfléchi souvent à cette problématique sans trouver la moindre idée de comment faire, je peux dire que je suis soufflé. Reste à mettre en œuvre Sourire.

visualcomplexity.com cité.

Une excellente astuce, pleine de bon sens : sur un graphique de relations d’une personne, inutile de mettre tous les liens qui partent directement d’elle (et même inutile de placer cette personne), vu que le contexte fait qu’il y en aura obligatoirement autant que d’autres personnes.

Pour ce qui est de la Dataviz pour Big Data, la réponse à la question de la session est qu’il faut passer par une étape d’analyse, car les Dataviz savent afficher des millions de données, mais pas des milliards. Une étape d’analyse est nécessaire. A mettre en lien avec la session sur le Big Data pas toujours utile pour amener de la valeur…

L’envers du décor : le Modern-ALM dans – et par – les équipes produits Microsoft

Bon, je ne vais pas faire de compte-rendu sur celle-là, vu que je la présentais. Je laisserai faire les personnes présentes, en les remerciant pour leur intérêt. Un grand merci à Jean-Marc Prieur d’avoir joué le jeu de l’interactivité ! Et je garde en tête le Remote Office, pour transformer un Windows Phone en pointeuse PowerPoint Sourire.

C’était une expérience très intéressante. J’ai appris énormément sur les bonnes pratiques Lean, ne serait-ce qu’en préparant cette session. Microsoft est vraiment un modèle pour cela. J’avais déjà compris qu’ils étaient en avance en traduisant Hard Code, d’Eric Brechner, mais en voyant leurs méthodes de travail et le niveau atteint par les outils internes… on se dit qu’il nous reste du boulot !

Plénière Jour 2

Présentation d’un monde changeant : Cloud, objets connectés, urbanisation galopante. Dans tous les sens du terme, d’ailleurs, vu le projet Smart Cities.

Démo impressionnante sur l’amélioration de performance grâce à un SQL In Memory. Je reste curieux de savoir si ça peut battre une approche de type prévalence objet. Clairement, pas en termes de vitesse de développement objet, mais en termes de performance pure, ça vaudrait le coup de tester. Là encore, peut-être un prochain billet de blog, si je me plonge dans SQL Server 2014. Mais j’ai déjà du boulot avec PowerBI, et tout le reste…

Information importante : fin du support de Windows 2003 R2 en Juillet 2005. On parle beaucoup de XP pour Avril 2014, mais le même sort pend au nez de ceux qui utilisent encore du 2003. A vos migrations !

Content de voir que Power Query, techno que j’adore, est montrée en plénière. Un meilleur choix de donnée, avec un jeu bien pourri qu’on purifie en quelques actions, aurait été encore plus édifiant. Power Q&A est également impressionnant, mais j’avoue ne pas être convaincu par le “langage naturel”. Il faut quand même respecter une syntaxe donnée. Vus les commentaires entendus dans les couloirs, je n’étais pas le seul. Bref, à tester pour se faire une idée réelle.

Créer des jeux pour Windows Phone et Windows Store avec Unity

Dur de faire une retranscription du contenu, vu que c’était de la pure démo de la conception d’un jeu en une vingtaine de minutes, avec Unity 3D. Les conférenciers connaissaient bien leur sujet. Un peu trop de remarques toutefois sur leur business et un niveau d’éloquence laissant bien trop à désirer à mon goût. Mais il n’est pas impossible que je sois juste un vieux c…

Arctic Unity Game Kit : tutoriaux recommandés.

unityvs.com pour voir le plugin Visual Studio pour faire du Unity 3D. Sinon, c’est MonoDevelop, vu que le core est basé sur Mono. Intéressant pour faire du débogage.

Ayant une connaissance quasi-nulle du développement de jeu, je dois dire que ce qui paraissait extraordinairement difficile il y a quelques années est en train de devenir à portée d’un bon développeur.

Portable Class Libray & Nuget : le combo gagnant

Le niveau intermédiaire ne reflétait pas le contenu, très introductif. Très bien pour des débutants, mais pas niveau 200.

L’urbanisation du collaboratif pour aller vers un portail intranet unifié, l’enjeu de demain

Idée maitresse : l’unification est-elle possible entre un annuaire, une GED collaborative, des réseaux sociaux et des outils de communication unifiée. Mais la session part plutôt sur des retours d’expérience sur quatre cas particuliers, et ne traite finalement pas d’intégration de ces services.

La comparaison d’un humain avec un “hub de communication” me laisse personnellement dubitatif…

Conversations < livrables < modèles < régles (capitalisation + quand volume –)

“L’entreprise connectée” de Sogeti : e-book gratuit. A voir.

La démystification du Big Data

Bon, une session qui part bien. Quand il y a Benjamin Guinebertière, ça va être du sérieux. C’est le cas, même si je déplore que la session soit surtout une présentation de pratiques Big Data. Je ne vois pas de remise en question ou de démystification.

Au contraire, je vois même passer beaucoup de biais habituels du Big Data. Sur une moisson de conversations utilisées pour réaliser une analyse Big Data, le tweet “J’irais jouer à la PS4” est noté comme avis positif. Ou bien, sur une analyse sémantique, les marqueurs de négation ne sont même pas pris en compte (du coup, l’argument de l’orateur expliquant que le fait de ne pas détecter les sens complexes comme le sarcasme en prend un sérieux coup). Cette première démo se fait à une vitesse démentielle, en cliquant partout à fond et en montrant des tas de scripts. Pourquoi ne pas prendre un ou deux sujets particulièrement importants et les expliquer ?

WordCount

La seconde démo est l’inverse de la première : beaucoup de pub pour la marque, très peu de technique et au contraire, une approche de type “magique”. Je ne pense pas que le public des Tech Days soit venu chercher ce genre de discours… Et non, il n’y a pas 36 000 cantons en France. Il y a 36 000 communes.

La description de l’architecture complète était intéressante, mais un poil incomplète. Tous les flux n’ayant pas été expliqués, on ne comprenait pas la consistance du tout.

Architecture

Shapefile et Shapely permettent de faire du mapping coordonnées / communes en Python.

Un point intéressant démontré est la limite atteinte sur la multiplication des nodes pour améliorer la performance. La parallélisation s’arrêtait pour des raisons de composition de données (le nombre de cores atteignait la granularité des ensembles de données). Très bien d’avoir poussé le test, et de l’avoir mis en lien avec le coût.

Le reporting BI dans tous ses états / quel outil pour quel usage

Astuce : la touche CTRL permet de déplacer la sélection dans une chronologie (les segments adaptés au temps dans un Tableau Croisé Dynamique d’Excel).

Powershell et les techniques de remoting

Bon, ben voilà une vraie session de niveau 300 Sourire.

Powershell 2.0 : computername en paramètre dans 35 cmdlets

Powershell 3.0 : Get-CIMInstance, sessions déconnectées et robustes, etc.

Nouveau paradigme : WinRM avec 2 ports fixes plutôt que l’approche DCOM/RPC ancienne qui posait des problèmes aux pare-feu. WinRM est basé sur WS-Management, et donc sur SOAP.

Je passe sur les méthodes pour activer, démontrées de manière très complète, mais sujet trop technique pour ce compte-rendu général / d’astuces / de compréhension.

Deux modèles :

  • Fan out : 1 to N (Invoke-Command, c’est-à-dire qu’on envoie à N machines une même commande et qu’on agrège les résultats).
  • Interactif : 1 to 1 (ssh-style, à savoir qu’on pilote une machine à distance).

Bonne pratique : en mode Fan out, bien penser à utiliser Select-Object pour ne sérialiser que les attributs dont on a besoin en retour, sinon avec quelques centaines d’ordinateurs pilotés, ça peut faire mal à la bande passante.

La paramètre AsJob de InvokeCommand permet de lancer des traitements en asynchrone. On fait ensuite un Get-Job pour voir si c’est terminé, et un Receive-Job pour récupérer les résultats.

New-PSSession crée un canal de communication fixe.

Intéressant : le remoting implicit permet d’associer des commandes à une session particulière sur laquelle on a importé des modules.

Powershell 1.0 et 2.0 : WMI / Powershell 3.0 et 4.0 : CIM.

Et en rentrant…

Une pensée pour les gens qui, en Bretagne ou ailleurs, ont les pieds dans l’eau. Un passage en TGV montre à quel point les dégâts sont importants.

Inondations

Posted in Retours | Tagged | 8 Comments