Perl 6 et MD5 dans la même phrase ???

Posted on 30/10/2014 by JP Gouigoux

Nous sommes en 2014, cela fait quoi… dix ans qu’on a démontré que MD5 n’était pas résistant aux collisions. L’algorithme est donc obsolète depuis une décennie.

D’un autre côté, toute nouvelle version de Perl. Là encore, dix ans depuis la 5.000. Bref, avant de sortir la version 6, on peut dire qu’ils ont pris leur temps.

Eh bien, accrochez-vous bien ! Si vous allez sur http://perl6.guide/, et que vous cherchez le tout premier exemple de code dans cette toute nouvelle version du langage, sur quoi tombez-vous ? MD5 ! Sérieux ???

image

Jusqu’à maintenant, j’avais tendance à ne pas trop me moquer de Perl 6 ou d’autres langages de vieux, n’étant moi-même pas vraiment de la dernière génération. D’autres, comme la newsletter de CodeProject, y vont franco :

image

Mais après un tel exemple, comment tenir ?

Posted in Uncategorized | Leave a comment

Kinect et migration au SDK v2

Posted on 12/10/2014 by JP Gouigoux

Comme je l’expliquais dans un précédent article, j’aime bien utiliser la Kinect pour faire comprendre l’importance des tests unitaires avant de passer aux tests d’intégration à mes étudiants. Ca fait deux ans que j’utilise ce TP avec une Kinect de première génération, mais j’ai reçu la V2 depuis quelque temps (je fais partie du programme beta) et de caractère joueur, je pense que je vais tenter mon prochain TP avec une version beta du SDK V2 Sourire

Mais pour cela, il va d’abord falloir faire fonctionner mon code existant sur la nouvelle API, qui a bien changé pour ce qui est de la reconnaissance de squelette. Le but du présent article est de documenter la migration.

Librairies

La librairie de base pour faire du .NET s’appelle toujours Microsoft.Kinect.dll, mais elle se trouve désormais dans C:\Program Files\Microsoft SDKs\Kinect\v2.0-PublicPreview1409\Assemblies\ (en tout cas, pour cette beta du SDK).

Attention, il faudra passer votre projet en .NET 4.5, dans l’onglet Application des propriétés du projet, pour que la librairie soit acceptée :

image

Détection des senseurs

Voici l’ancien code pour récupérer le périphérique Kinect courant (on peut en brancher plusieurs, mais dans 99% des cas, on n’en utilise qu’un) :

foreach (var potentialSensor in KinectSensor.KinectSensors)
    if (potentialSensor.Status == KinectStatus.Connected)
    {
        this.sensor = potentialSensor;
        break;
    }

L’API en nouvelle version permet de gérer beaucoup plus facilement ce cas standard :

this.kinectSensor = KinectSensor.GetDefault();

Au passage, il n’y a pas d’autres méthodes pour choisir un senseur dans cette classe, donc je ne sais pas comment on fait avec de multiples Kinect. Ca aussi, ça a changé…

Ouverture du flux

Le flux de données lié à la détection corporel s’ouvrait précédemment avec du code à peu près comme suit :

if (null != this.sensor)
{
    this.sensor.SkeletonStream.Enable();
    this.sensor.SkeletonFrameReady += this.SensorSkeletonFrameReady;
    this.sensor.SkeletonStream.TrackingMode = SkeletonTrackingMode.Seated;
    try { this.sensor.Start(); }
    catch (IOException) { this.sensor = null; }
}

On procède désormais différemment, en utilisant un véritable flux de lecture, et plus simplement un évènement :

this.bodyFrameReader = this.kinectSensor.BodyFrameSource.OpenReader();
this.kinectSensor.Open();
this.bodyFrameReader.FrameArrived += this.Reader_FrameArrived;

Il y a donc une surcouche par rapport à l’API précédente, qui faisait lire directement le flux sur le capteur. Désormais, c’est bien une classe de type Reader qui renvoie les informations. Plus logique…

Gestion des évènements

Logiquement, la signature des méthodes appelées est bien différente. Voici l’ancienne :

private void SensorSkeletonFrameReady(object sender, SkeletonFrameReadyEventArgs e)

Et voici la nouvelle :

private void Reader_FrameArrived(object sender, BodyFrameArrivedEventArgs e)

Les classes d’arguments étant différentes, le code pour les exploiter suit le mouvement. Dans l’ancien, on récupérait des instances de Skeleton :

using (SkeletonFrame skeletonFrame = e.OpenSkeletonFrame())
    if (skeletonFrame != null)
    {
        skeletons = new Skeleton[skeletonFrame.SkeletonArrayLength];
        skeletonFrame.CopySkeletonDataTo(skeletons);
    }

Désormais, ce sont des instances de Body :

using (BodyFrame bodyFrame = e.FrameReference.AcquireFrame())
{
    if (bodyFrame != null)
    {
        if (this.bodies == null)
            this.bodies = new Body[bodyFrame.BodyCount];
    }
}

Changements dans les jointures

Pour les jointures (au sens du corps humain, pas SQL), on récupère toujours le contenu de Joints, avec une énumération JointType.

Attention, toutefois, car certains types de jointures ont été remplacés. Par exemple, la jointure ShoulderCenter n’existe plus. Le nouveau modèle de squelette est maintenant plus complet, et offre une description de la colonne vertébrale, ce qui nous amène à utiliser SpineShoulder à la place.

Et la suite au prochain épisode !

Posted in C# | Tagged | 2 Comments

Interrompons les développeurs !

Posted on 18/08/2014 by JP Gouigoux

This article is also available in English.

Le contexte

Vous êtes peut-être comme moi tombés récemment sur des articles expliquant qu’il ne faut surtout pas interrompre des développeurs dans leur travail. C’est un peu comme mettre de l’eau sur un Gremlin : le monde s’écroule si le pauvre garçon (ou la pauvre fille, mais il y en a très peu parmi nous, et surtout je ne les vois pas se plaindre de la sorte) est interrompu.

Il y aurait, il parait, ce “flow”, état quasi-mystique dans lequel le développeur se plonge progressivement et devient capable, sous pleine concentration, de miracles de rapidité en programmation. Jamais de question sur la qualité du code ainsi produit, mais bon…

Au cas où vous auriez raté la mode, voici quelques liens, parmi tant d’autres :

http://www.infoworld.com/d/data-center/no-interruptions-technologist-work-247487

http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

http://programmers.stackexchange.com/questions/46252/how-to-explain-a-layperson-why-a-developer-should-not-be-interrupted-while-neck

http://blog.ninlabs.com/2013/01/programmer-interrupted/

http://casa-laguna.net/all-the-news/show/do.-not.-ever.-interrupt.-a-programmer

http://www.drdobbs.com/tools/just-let-me-code/240168735

La réalité

Oui, bien sûr qu’il faut ménager des moments calmes pour avancer sur du code de manière efficace, mais c’est vrai de n’importe quel type d’activité. Idem pour lire un livre, s’endormir, écrire un article de blog, etc. La plupart des activités (surtout réalisées par des hommes, qui ne sont pas multitâches Sourire) nécessitent que leur auteur n’ait pas son attention morcelée pour être réalisées efficacement. Ce sont des comportements de diva de faire croire que c’est plus important pour les développeurs que pour les autres.

Et surtout, c’est révélateur d’une façon de penser qui pose plusieurs problèmes, de mon humble point de vue.

Problème n°1 : certains pensent que coder est l’activité principal d’un développeur

Je plaide coupable, parce que j’ai longtemps eu ce biais. Je ne compte pas le nombre de programmes que j’ai codés le soir chez moi sans aucune autre utilité que de coder sans avoir à faire de documentation, d’analyse, de schémas explicatifs… J’ai même publié du code en Open Source alors que son utilité pour d’autres (comme le montre le faible nombre de téléchargements) était on ne peut plus limitée.

Avec un peu de recul (le “un peu” est destiné à ne pas me sentir trop vieux, ça fait 28 ans que je code), je sais maintenant que le code représente un quart, maxi 30% du métier de développeur si on veut l’exercer à peu près proprement.

Problème n°2 : est-ce la bonne façon de programmer ?

Si vous avez besoin de 15 minutes pour rentrer dans votre projet, c’est qu’il n’a pas été assez décomposé et la complexité de chaque portion est donc encore trop grande pour être traitée sans incorporer un tas de bug.

S’il faut autant de temps pour remonter la pendule cérébrale d’un développeur à un point où elle sera en mesure de continuer à avancer, c’est que le sujet n’a pas été suffisamment modélisé. Lordon parle d’une “frontière technique”, où des concepts et du vocabulaire spécialisé sont mobilisés pour atteindre rapidement un état dans lequel l’intellect peut continuer à avancer sur une discipline. Peut-être que notre discipline, pourtant pleine de jargon mais très technique, manque de moyens intellectuels et de raccourci sémantique sur la modélisation ?

Problème n°3 : le “flow” est une belle invention…

… mais il y a de bonne chance pour que, lorsque vous le ressentez, vous soyez simplement dans un mouvement de routine. Un peu comme quand vous jouez à Five Dots, et que le fait de supprimer des points devient hypnotique. Vous perdez de vue l’idée de diminuer votre score, et vous finissez par jouer machinalement.

Même chose pour le code : nous avons tous expérimenté ce moment où, pris dans ce “flow” (ou n’importe quelle autre façon de désigner une simple concentration sur un sujet unique), nous nous retrouvons à ajouter des fonctionnalités non prévues, voire seulement prévoir des cas sans qu’ils aient été clairement définis comme des besoins réels de nos utilisateurs.

Vous voulez vous en convaincre ? La prochaine fois que vous sortez du fameux “flow”, supprimez tout le code que vous venez d’écrire. Et recommencez. Vous vous apercevrez que la deuxième fois va beaucoup plus vite, qu’elle ne nécessite pas une concentration particulière (évidemment, puisque vous avez cette fois-ci fait l’effort de décomposer le problème avant de rentrer dans le code) et surtout qu’elle aboutit à un code plus compact et plus propre.

Problème n°4 : une bonne part de fatuité

L’impression que j’ai est que de nombreux développeurs se cachent derrière cette notion de “flow” pour faire croire qu’ils sont très bons en code. Et cette façon d’insister sur l’importance capitale de ne pas interrompre les développeurs (voir tous les liens plus haut, et il suffit de chercher pour en trouver des tas d’autres) sent un peu l’envie de profiter que les gens ne comprennent pas notre travail pour leur raconter n’importe quoi et continuer tranquillement à coder sans faire attention à la qualité autant qu’on devrait.

La qualité du code est toujours un problème, la discipline de l’ingénierie informatique étant encore très jeune par rapport aux autres disciplines d’ingénierie. Il est donc encore plus important de se garder de cette fausse impression de qualité alors que le “flow” est simplement un état de concentration autorisé par le fait qu’on ne réfléchit qu’à une seule chose : le code (et comme dit plus haut, pas ses impacts, ni ses fonctions secondaires, etc.)

Est-ce que mes projets Open Source ou les rares fois où j’étais dans le soi-disant “flow” au bureau ont produit quelque chose de mieux que du code que j’ai réalisé petit à petit ? La réponse est non. Il y a bien eu quelques bouts de code importants (utilisés en production par quelques milliers de clients), mais ils ne sont au final pas de meilleure qualité que d’autres.

Aujourd’hui, si je dois passer plus de dix minutes à coder une fonctionnalité, je ne commence même pas à coder, car ça veut juste dire que je n’ai pas encore suffisamment décomposé le problème pour pouvoir le coder de manière efficace et avec le bon degré de qualité dans chacun de ses composants…

Et tant qu’on y est

Peut-être que c’est le bon moment pour essayer de régler leur compte à quelques imbécilités qu’on lit sur le sujet :

  • Instant Messaging “If you really, really need me, you can interrupt, but expect a grumpy return.” (source) : si c’est tellement important d’être dans le soi-disant “flow”, est-ce que ça ne serait pas tout simplement moins bête d’éteindre Messenger ?
  • Même chose pour Skype (source).
  • La comparaison avec arrêter un chirurgien dans son boulot est peut-être le pompon (même endroit que le point précédent) : en plus d’être d’une vantardise extraordinaire (sérieux, il y a peut-être 1% d’entre nous informaticiens qui bossons sur des programmes dont dépendent des vies), la comparaison est de toute façon erronée : sur une opération qui dure quelques heures, un chirurgien s’interrompt sans arrêt, utilise l’aide de ses assistants, explique à un interne la façon dont il procède, etc. Il ne se colle pas un casque sur les oreilles pour travailler tranquille, quitte à faire des erreurs que personne ne pourra contrôler.
  • Et tellement d’autres que je ne vais pas m’appesantir là-dessus…

Conclusion

Interrompons les développeurs ! Sérieusement ! Si vous voyez un développeur qui a son casque sur les oreilles et qui ne fait que taper sur son clavier depuis deux heures, stoppez-le… Dites-lui de prendre une pause, de réfléchir deux minutes à ce qu’il fait, de vous l’expliquer. Dites-lui de faire un schéma, de reposer avec vous une autre façon de décomposer le problème en classes. Pensez-vous vraiment qu’il n’aura rien à reprendre sur son code pondu en une seule séance ? Qu’à deux vous n’aurez aucune idée d’amélioration ?

Posted in Uncategorized | 8 Comments

Quelques notes sur Service Design Patterns

Posted on 16/08/2014 by JP Gouigoux

Quelques semaines seulement après avoir publié une liste des dix livres que je considère comme fondamentaux pour un informaticien, je viens de finir un autre bouquin qui aurait été un excellent candidat : Service Design Pattern, de Robert Daigneau.

Douze post-it coincés dans un bouquin pour garder trace de points importants, c’est un record personnel Sourire. Alors, je me disais que ça valait le coup, non pas de faire réellement une revue du livre, mais plutôt d’expliquer ces quelques points qui m’ont paru importants. En particulier, de les commenter au regard de mon expérience actuelle de migration d’un ensemble applicatif d’un éditeur de logiciel vers une architecture SOA.

Notion de couplage

J’ai souvent entendu parler de deux types de couplage seulement, à savoir le couplage comportemental et le couplage temporel. De plus, on a souvent tendance à parler du couplage comme quelque chose de binaire. La page 9 explique bien que le couplage est plutôt une valeur plus ou moins forte, et qu’il est impossible (et pas souhaitable) d’atteindre des architectures complètement découplées.

Pour moi, c’est un peu comme la différence entre des langages fortement typés et des langages à typage dynamique. Le contrôle par compilateur correspond à un contrôle fort en amont, avec du typage. A l’inverse, les langages dynamiques sont plus permissifs sur les types, mais cela ne veut pas dire qu’ils ne connaissent pas les types. Il y a moins de couplage, mais il y en a toujours. Moins – en gros, n’avoir que des chaînes – ne servirait à rien.

C’est un peu la même chose pour le couplage : il est inutile d’essayer de le réduire à néant, car on élimine alors toute la sémantique métier avec, alors que les difficultés techniques associées ne baissent plus tellement.

Pour en revenir aux types de couplage, le livre utilise plutôt une décomposition en quatre types, plus techniques et donc plus faciles à comprendre : fonctionnel, structurel sur les données, temporel et sur l’URI. Ce dernier type de couplage, je trouve, est particulièrement sujet à approfondissement, car il est en lien avec l’utilisation de registres ou annuaires de services. Or, ce sujet est complexe, car la mort d’UDDI ne veut pas dire que les besoins initiaux qui avait prévalu à sa conception ont disparu pour autant… Mais j’y reviendrai un peu plus loin.

WSDL comme une documentation lisible par une machine

J’ai bien aimé la petite note à la page 15 expliquant que même si WSDL est prévu pour une exploitation de la définition d’un service par une machine, il ne peut que capturer une petite partie de l’information nécessaire pour utiliser ce service.

On a souvent tendance à se dire que WSDL porte une bonne partie du service, et qu’il suffit de rajouter quelques métadonnées sémantiques pour que la description soit complète. Mais c’est un piège qui amène au mode de développement “code –> WSDL –> proxy auto-généré –> code”, chargé à bloc en couplage technique.

Après, c’est vrai que ça serait bien que la norme embarque une gestion des échecs un peu plus détaillée, mais c’est bien de rappeler, surtout dans un bouquin technique pour des informaticiens qui n’aiment pas ça, qu’un service est surtout décrit par sa documentation (oui, je sais, j’utilise des gros mots).

Quelques considérations sur le pattern Linked Service

Le pattern Linked Service consiste à envoyer dans la réponse d’un service la liste des URI qui correspondent aux opérations qui auraient du sens à être appelées par la suite. Le cas typique est dans AtomPub, lorsqu’on renvoie sur l’URI d’un article complet, ou dans OData quand on fournit le token pour voir la page suivante de données.

Le livre, en page 79, fournit quelques excellentes remarques sur la sécurité et la génération des URIs. Je n’avais personnellement jamais pensé au problème effectivement élevé d’attaques de type MITM sur ce pattern, mais je sais maintenant qu’il faudra mitiger le risque. Le problème peut en plus être aggravé par le fait que le client peut, grâce à ces données, devenir de plus en plus léger, et se contenter de présenter les URIs avec leurs métadonnées descriptives (format XLink, OK, mais les valeurs ne sont pas encore normalisées). Or, si le client devient trop bête, il y aura encore moins de chance qu’il valide que les données n’ont pas été modifiées depuis leur envoi par le serveur.

Par contre, il va falloir réfléchir sérieusement sur la bonne façon de mettre ce pattern en action dans SOAP, car cette norme ne prévoit pas la notion de lien vers un autre appel. On retombe encore sur une raison d’utiliser plutôt REST, bien plus adapté à gérer les URIs. Bien sûr, SOAP est appelé sur du HTTP en général, mais REST utilise beaucoup mieux toutes les facettes de ce protocole.

Data-binding et Data Transfer Objects

La page 98 est une autre excellente ressource sur des points dont on ne parle pas souvent dans les autres livres sur les architectures SOA ou sur les services en général. Par exemple, le couplage provoqué par les solutions de data-binding. Même si des solutions existent pour le réduire, comme la classe ExtensionDataObject en WCF, le livre recommande des approches encore plus souples comme le pattern TolerantReader.

Un autre point sur le couplage entre les DTO et la signature : si vous voulez le réduire, il faut faire attention à limiter le nombre d’entités, et bien avoir des signatures très simples, avec juste une ou deux entités, et tout le temps les mêmes. Pas des versions réduites, ou alors carrément des URI.

Un peu plus loin en page 100, un rappel sur l’importance du “chunky, not chatty”, avec pour une fois une analyse des impacts sur la scalabilité, et la recommandation au final d’utiliser le pattern Data Transfer Object Collection.

La page 105 donne une approche du polymorphisme sur les DTO avec une référence XSD à un type abstrait dont je n’avais jamais entendu parler dans aucune autre ressource internet ou aucun livre. Ou plutôt, j’avais surtout entendu que c’était risqué, mais le livre montre (avec le code associé) comment faire de manière simple et efficace.

Service connectors

En page 171, j’ai trouvé une explication claire sur un sujet qui était nébuleux depuis longtemps. Nous savons tous qu’UDDI est mort, mais il y avait quand même un besoin derrière la création de cette norme, même s’il a été surchargé avec des tas de trucs inutiles sous lesquels elle s’est finalement écroulée. Alors, comment gérer de manière propre le besoin de ne pas avoir des proxies qui accèdent directement à des services ?

Les deux solutions proposées sont le Service Registry (connu) et le Virtual Service (dont c’est la première fois que j’entendais parler en tant que pattern reconnu). Il y a aussi le Service Gateway qui peut être utile dans les cas les plus complexes.

Pour ce qui est de l’approche routage, on peut utiliser WS-Routing, mais aussi un reverse-proxy, ou même passer par le DNS. Par contre, il y a des choses dans le registre de services qui peuvent être intéressantes en plus : les policies (WS-Policy), les règles d’appels (seulement pendant les heures ouvrées, par exemple), etc. Là encore, il faut faire un choix en fonction du niveau de fonctionnalité dont on a vraiment besoin, et ne surtout pas se retrouver à mettre en place un registry si c’est pour gérer un changement d’URL tous les deux sur des contrats à version unique…

Gestion des contrats

La page 177 contient des arguments REST intéressants contre les contrats formels. Venant plutôt du monde SOAP mais appréciant la simplification proposée par REST, je me disais que la perte de contrats formels restait gênante, et que des initiatives comme WADL étaient à étudier, mais je me suis rendu compte à la lecture de cette page et des suivantes qu’on pouvait se baser sur HTTP et toute sa richesse plutôt que de recourir à d’autres technologies.

Idempotence

Toute la partie sur l’idempotence est absolument excellente, et une des plus documentées que j’ai lues. En page 208, il y a une discussion sur le pattern Idempotent Retry, et l’utilisation du code HTTP 503 avec un header Retry-After qui n’est pas très connu. Attention, ce genre de comportement est surtout recommandable avec des services de type ressources, sinon on se retrouve avec une ambigüité sur l’exécution de la commande. Ce n’est pas parce qu’il y a idempotence qu’on peut se permettre de ne pas prévenir qu’il n’est inutile de relancer le service…

A propos d’idempotence, une astuce pour l’utilisation de la date de valeur de la commande, et qui servira pour l’historique sur l’entité, si elle est stockée : il vaut mieux utiliser la date du client plutôt que celle du serveur pour faciliter l’idempotence et éviter les effets dûs à l’asynchronisme. Après, il y a aussi des arguments pour utiliser celle du serveur (unification de l’ordre des entités, possibilité d’horodatage, etc.), mais il faut savoir les arguments des deux côtés pour bien choisir.

Le retour de ce genre de service sera typiquement un acknowledgement plus un Linked Service, qui pourra servir à surveiller si la commande a finalement abouti. Ceci permet de mettre en place un asynchronisme de manière simple.

Tests des contrats de services

Page 253, une rareté : des idées solides sur les tests. C’est suffisamment rare pour le souligner, que de voir parler de tests dans un livre dont ce n’est pas le sujet principal. En plus, la décomposition des tests est très claire, avec quatre points à tester : le contenu (auquel on pense en premier), le contexte d’exécution (plus rare), le comportement (codes de retour, headers, etc., souvent laissés de côté) et la qualité de service (dont on ne sait souvent pas quoi vraiment faire).

En page 257, un petit complément sur l’utilisation d’IIntegrationContext dans NUnit, pour configurer un client HTTP sur un fake de Service Connector.

Le bouquet final

Et pour finir, cinq pages extraordinairement complètes sur la façon dont les patterns qui ont été expliqués dans le livre peuvent améliorer ou au contraire dégrader la capacité d’évolution des services. Pour le coup, c’est la première fois que je vois une étude aussi approfondie sur ce sujet. D’habitude, les livres ou les articles se contentent d’expliquer les patterns, avec leurs point positifs et négatifs, mais ne creusent pas beaucoup sur leur mise en application, comment ils impactent le développement dans le long terme. Là, on sent que l’auteur a une longue expérience pour pouvoir juger de si un pattern a une influence sur l’évolution d’un service.

Conclusion

Si vous voulez vous instruire sur les architectures orientées services, Service Design Patterns est une lecture obligatoire.

Petite note additionnelle : si vous vous posez la question de l’extensibilité des contenus de services web, et que vous vous demandez pourquoi XML Schema a l’idée bizarre de ne pas considérer comme valide tout ce qui est supplémentaire au schéma, jetez un œil à Schematron.

Et une toute dernière astuce pour la route : si vous avez une équipe en charge des services, faites-lui réaliser aussi les APIs pour appeler ces services. Personne d’autre qu’elle ne saura mieux comment réaliser les requêtes, et vos clients ne passeront pas leur temps à générer des proxies sans savoir à quoi ils servent, ce qui génère du couplage technique.

Posted in Retours | Tagged | 2 Comments

Teasing : nouveau livre en approche !

Posted on 15/08/2014 by JP Gouigoux

Après mon quatrième sur PowerPivot (voir annonce ici) il y a quelques mois à peine, je suis fier de vous annoncer que le cinquième est en phase de lancement. Je viens de faire parvenir le PDF à O’Reilly pour publication, et ça devrait être en ligne d’ici quelques semaines maxi.

J’ai créé une page dédiée avec tous les détails, et que je complèterai bientôt avec l’URL pour acheter l’e-book. Une version papier existera, mais uniquement s’il y a de la demande : si cela vous intéresse, laissez-moi un commentaire sur cette page.

image

Petite note à l’attention de mes chers collègues : il s’agit d’une lecture obligatoire ! Sourire

Posted in Uncategorized | Tagged | 6 Comments

Espace disque manquant

Posted on 01/07/2014 by JP Gouigoux

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

Posted on 01/07/2014 by JP Gouigoux

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

Posted on 01/07/2014 by JP Gouigoux

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

Posted on 01/07/2014 by JP Gouigoux

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 | 6 Comments

Premier cours aux Mines

Posted on 26/06/2014 by JP Gouigoux

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