Evènement Microsoft Extend à Paris, les 11 et 12 mai

Microsoft ouvre une conférence décrite comme “crowd-conferencing” (c’est-à-dire que c’est le public qui aura une part de vote pour les sessions qui seront présentées). Au menu, Office, Machine Learning, Cortana Analytics Suite, Power BI et SQL Server, et des intervenants qui viennent de Microsoft Corp à Seattle (http://www.interopevents.com/paris2016#paris2016-speakers).

image

Et c’est ouvert à tous, pas qu’aux MVP !

Posted in Uncategorized | Tagged | Leave a comment

Journée des interfaces naturelles sur le Campus Microsoft

Pour les veinards qui sont sur Paris, Microsoft organise le 11/12 une journée avec du Kinect, du projet Oxford, du Cortana, de l’IoT, etc.

Au programme, 4 MVPs qui vont vous faire découvrir tout ça ! Et peut-être que Microsoft aura amené un Hololens ? Pretty please Sourire

Pour s’inscrire, c’est ici : https://msevents.microsoft.com/CUI/EventDetail.aspx?CR_CC=200708369&EventID=1032691529&Culture=fr-FR&community=0

Posted in Uncategorized | Tagged | Leave a comment

Carina de Rackspace : un Docker Swarm en ligne

Imaginons que vous souhaitiez utiliser un cluster de machines pour déployer vos conteneurs Docker, en faisant en sorte que ces machines apparaissent comme une seule machine hôte Docker. Vous pouvez bien sûr monter ce genre de configuration chez vous avec des machines physiques ou virtuelles, mais le plus simple, à l’ère du cloud, est de tout simplement laisser des pros s’occuper de toute la tringlerie et pointer sur un hôte multi-machines, avec le réseau déjà paramétré ainsi que tout ce qui est compliqué (gestion des ressources, scaling, etc.)

C’est ce que propose Rackspace avec le produit Carina, qui est actuellement en beta, et gratuit. Pour tester un peu ce dont il retourne, commencez par vous créer un compte sur https://app.getcarina.com/app/login et connectez-vous :

image

Créez ensuite un cluster en cliquant sur “Add cluster” dans la fenêtre qui s’affiche, et renseignez l’identifiant et si vous souhaitez qu’il passe automatiquement à l’échelle :

image

De retour au panneau de contrôle, avisez le cluster nouvellement créé et cliquez sur GetAccess :

image

Le fichier téléchargé contient le nécessaire pour que vous vous connectiez sur votre cluster. Dans un shell Linux, lancez le fichier docker.env pour qu’il configure les variables d’environnement nécessaires :

DIR=$( cd “$( dirname “${BASH_SOURCE[0]}” )” && pwd )
export DOCKER_HOST=tcp://172.99.79.150:2376
export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=$DIR

export DOCKER_VERSION=1.8.3

Attention à bien lancer le fichier avec la commande “source docker.env” ou en utilisant “.” à la place, car si vous exécutez simplement, un nouveau shell sera lancé et les variables ne seront pas modifiées dans le shell courant. A propos, ne vous inquiétez pas pour votre installation locale de Docker : seul le shell en cours prendra ces modifications.

On voit d’ailleurs, si on lance une autre fenêtre de shell que les informations sur Docker correspondent à une installation locale :

jpg@Ubuntu1410:~$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18

Go version (server): go1.4.2
Git commit (server): 7c8fca2
OS/Arch (server): linux/amd64

Alors que dans la fenêtre dans laquelle vous avez activé docker.env, les informations sont légèrement différentes (pour la partie serveur, en tout cas, car la partie cliente utilisée est celle locale) :

jpg@Ubuntu1410:~/carina/TestJPG$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: swarm/0.4.0
Server API version: 1.16
Go version (server): go1.4.2
Git commit (server): d647d82
OS/Arch (server): linux/amd64

Attention, vous devez avoir une version du client Docker assez récente pour que Carina soit pilotable correctement.

A partir de là, toutes les commandes Docker que vous lancerez auront pour effet la création de conteneurs ou le chargement d’images sur le cluster distant. Imaginons par exemple que vous démarriez un serveur Nginx avec une commande comme :

docker run -d -p 80:80 –name web nginx

L’adresse d’exposition ne sera alors plus votre machine locale, mais une machine publique sur internet dont vous pouvez retrouver l’adresse par exemple en lançant docker ps ou docker port :

jpg@Ubuntu1410:~/carina/TestJPG$ docker port web
80/tcp -> 172.99.79.150:80

A partir de là, il ne reste qu’à explorer la doc de Carina pour voir comment passer à l’échelle, gérer les volumes, etc. (d’après ce que j’ai pu en voir pour l’instant, elle est apparemment très bien faite), mais globalement, l’idée fondamentale est là : vous pilotez par l’API locale un hôte Docker distant, et multi-machines.

Attention, il s’agit d’une version beta sans aucune garantie de stabilité. Le site de Carina recommande d’ailleurs de passer le mode de gestion d’échec en “always retry” pour relancer les conteneurs tombés le cas échéant.

J’espère que le programme beta restera suffisamment longtemps gratuit pour que je puisse continuer mes tests et écrire quelques autres retours au-delà de cet article introductif…

Posted in Uncategorized | Tagged | Leave a comment

De la philosophie en programmation ?

En écrivant le blog précédent, qui finit par une recommandation de conceptualisation, je me suis rappelé d’une interview de Frédéric Lordon (philosophe et économiste passionnant à lire et à entendre) sur Arrêt sur Images. Il y citait Deleuze expliquant que la science procède par fonctions, alors que la philosophie procède par concepts (voir cette vidéo, à 5’55’’) :

image

Est-ce à dire que, comme Frédéric Lordon éprouve le besoin de convoquer Spinoza pour parler d’économie, nous aurions avons besoin de philosophie pour correctement conceptualiser les métiers que nous modélisons en informatique ? Je pense que oui, et je vais juste citer un exemple pratique sur lequel la philosophie m’a aidé de manière tout à fait pratique à lever une erreur de programmation.

Dans le livre “Sur les épaules de Darwin”, de Jean-Claude Ameisen, il est expliqué que le présent n’existe pas. Dans son style philosophique à la fois poétique et très scientifique, l’auteur convoque la mécanique quantique et la psychologie pour démontrer que la notion de présent est purement intellectuelle, et ne correspond à aucune réalité physique.

Il se trouve que cette réflexion rejoint parfaitement les travaux récents effectués sur un des logiciels dont je supervise la conception. Ce logiciel réalise des simulations budgétaires et jusqu’à maintenant, il fonctionnait de manière discrète, c’est-à-dire comme dans Excel, avec une modélisation du temps par colonne. Ainsi, nous avions des modèles financiers dans lequel le présent pouvait parfois correspondre à une année :

image

Malheureusement, il se trouve que certains sous-modèles financiers étaient calculés en mois, donc avec une représentation du présent différente :

image

Ceci pose des problèmes car il est difficile d’aligner les valeurs. Dans le sens d’une plus grande périodicité, c’est simple, il suffit de cumuler. Mais dans l’autre sens, comment faire : tout lisser uniformément ? La plupart des fois, ça ne correspond pas du tout à la réalité. De plus, cette définition du présent nous amenait à des représentations complexes, comme par exemple :

image

Non seulement le tableau est moins facile à lire, mais en plus, les lignes ne peuvent plus nécessairement être totalisées de la même manière.

Alors que si on reprend l’analyse philosophique d’Ameisen, et qu’on part du principe que le présent n’a d’existence que conceptuelle mais pas dans la physique, on tombe sur un modèle qui est beaucoup plus propre, où le présent n’est que la limite symbolique entre deux périodes seulement, qui sont le passé et le futur. Or, cette représentation est beaucoup plus propre au final, car elle permet de ne pas se soucier de la périodicité dans laquelle on discrétise pour représenter le présent :

image

Elle possède également l’avantage de pouvoir s’adapter à n’importe quelle périodicité, même la plus fine (pour de la trésorerie, au jour près, mais dans d’autres usages, nanoseconde si nécessaire). Bref, il s’agit d’une VRAIE conception du temps, et pas d’une représentation moyennement adaptée aux usages car trop rapidement posée.

Et si on pousse plus loin la conceptualisation, il faut d’ailleurs se poser la question de comment on pose cette ligne de présent ? Est-ce le moment où une personne analyse le budget ? Est-ce la date de valeur qu’on cherche à représenter dans le budget ? On peut tout-à-fait imaginer une personne regardant le 3 mars le budget tel qu’il se trouvait le 15 décembre de l’an passé, etc. Bref, encore de quoi philosopher sur ce qu’est vraiment le présent… s’il existe !

Posted in Uncategorized | Tagged | 4 Comments

Silo or not silo ?

Après avoir lu de nombreux articles sur les problèmes des silos dans l’informatique (je ne vais pas faire la liste) ainsi qu’un article très intéressant car prenant à rebrousse-poil les précédents (article d’Hank Marquis) et quelques commentaires associés (ici et ), je vais essayer d’apporter mon humble pierre à l’édifice, en tentant de formaliser QUAND les silos sont mauvais et QUAND ils ont du bon.

L’idée est d’appuyer l’opinion d’Hank Marquis avec des retours d’expérience, et de participer ainsi à contredire les Docteur Follamour de l’architecture informatique qui pensent que détruire un SI pour le reconstruire “proprement” est une hypothèse envisageable dans la vraie vie.

Le bon silo et le mauvais silo

Les silos sont bons quand ils séparent des applications informatiques qui n’ont rien à voir, par exemple une application de gestion de fabrication et une application de paie :

image

Inutile en effet de mélanger les choux et les carottes : une étanchéité “physique” permettra de ne pas risquer que les problèmes de l’un n’affecte l’autre (ex : plus de place sur un serveur de base de données commun, ou un changement de version des documents générés pour la bureautique, j’en passe et des meilleurs)

Les silos sont mauvais lorsqu’ils conduisent à de la duplication de données, par exemple si une application gère des bénéficiaires de subventions et l’autre des destinataires de courriers, car il y a de bonnes chances que ce soient des mêmes personnes qu’ils s’agissent (même si chaque application aura bien sûr ses spécificités de traitement des personnes, voire ses propres données complémentaires) :

image

Les problèmes sont là aussi multiples : duplication des commandes de modification des enregistrements, risque de ne pas avoir la même adresse pour le même tiers dans les deux silos, etc. La duplication des données dans les SI industriels est une des principales causes de perte économique.

Première approche d’interop

La réponse des EAI et ETL étaient de relier les silos par des mécanismes informatiques d’échange de données automatisés. Cela fonctionne assez bien quand il n’y a que deux ou trois silos avec des formats différents :

image

Mais les EAI posent le problème d’un Single Point Of Failure (en tant que point central, s’il dysfonctionne, tout le système est hors service). De plus, passé 4 à 5 silos échangeant de la donnée, on perd plus de temps à synchroniser techniquement qu’à travailler réellement sur le métier des applications, et on recrée dans l’EAI le plat de spaghetti dont on cherchait à se débarrasser dans le SI :

image

Approche d’interop plus moderne

La solution est de passer à des architectures orientés services, et de ressortir dans notre exemple un référentiel des personnes :

image

Mais, et j’en reviens à l’article de Hank Marquis, en mettant en place ce référentiel, il est important qu’il soit complètement autonome et le plus indépendant possible des autres métiers qui le consomment… bref que lui-même se comporte comme un silo !

image

Et là normalement, vous me dites que je suis en train de me contredire car on retombe sur de l’EAI, avec des transformations dans tous les sens. En fait, non, car il y a le second effet kisskool : la centralisation, si elle est accompagnée d’une normalisation des échanges, permet de ne placer des connecteurs de médiation que sur les logiciels ne la supportant pas encore, et d’avoir une grammaire commune pour chaque entité du SI :

image

C’est typiquement dans ce cadre que des approches de type ESB s’épanouissent : connecteurs de médiation au standard Entreprise Integration Pattern, asynchronisme pour lisser les effets de la centralisation sur la performance, robustesse de livraison des messages pour contrebalancer la complexité dûe à l’augmentation des acteurs sont trois des responsabilités d’un bon ESB. Et un bon ESB est un allié précieux dans la mise en œuvre d’une architecture SOA, même s’il est appelé à s’effacer progressivement devant des API web standards (architecture WOA).

image

Attention aux cas particuliers

Est-ce à dire que tout doit être découpé et que chaque silo doit communiquer avec les autres ? Comme d’habitude, tout est affaire de juste mesure, et il y a des cas particulier. Imaginons par exemple le cas d’un SI RH. Il existe effectivement un peu de redondance entre les personnes en tant que salariés et les personnes en tant que bénéficiaires d’une bourse, par exemple leur patronyme ou leur adresse :

image

Et pourtant, est-ce que cela a du sens de dire que les agents d’une collectivité qui attribue des bourses doivent pouvoir espionner le salaire de leur collègue parce qu’il a demandé une bourse pour son enfant ? Bien évidemment que non. Si on creuse un peu plus ce concept de personne, nous nous rendons compte que les deux applications ne traitent pas réellement de la même chose. La gestion de bourses traite des personnes en tant que bénéficiaires (l’élève ou l’étudiant) ou mandataire (ses parents ou tuteurs qui reçoivent l’argent tant que le bénéficiaire n’est pas majeur), tandis que la gestion de paie traite des personnes en tant que salariés :

image

L’enseignement de ceci est qu’il est essentiel pour atteindre une bonne décomposition informatique des services d’avoir approfondi fortement la conceptualisation du métier. Par expérience professionnelle, je peux citer plusieurs cas où un défaut de conceptualisation a amené à des modifications d’applications se comptant en dizaines, voire centaines, de jours hommes. Juste pour donner une idée du niveau nécessaire à atteindre, continuons justement sur les “personnes”. Un concept que tout un chacun comprend, car il appartient à notre vie de tous les jours. Pourtant, sauriez-vous clairement définir la différence conceptuelle entre un individu, une personne, un tiers moral ou un tiers physique ?

Bref, comme toujours en informatique, on en revient à la compréhension du domaine métier. C’est le principe du Domain Driven Design de baser la conception informatique sur une grammaire partagée et décrivant de manière non ambigüe le métier ciblé. Souvent, cette compréhension du métier passe par son expression la plus pure, à savoir la loi. Pour l’exemple ci-dessus, c’est la règlementation qui donnera les règles de gestion des tiers (un exemple parmi tant d’autres : un tiers peut être moral et physique à la fois lorsqu’il agit en tant qu’auto-entrepreneur). Et pour revenir à la gestion des bourses, la loi dit que l’attributeur d’une bourse a droit de connaitre les ressources financières du demandeur. Evidemment, cela donne une idée du salaire du demandeur (ou du tuteur éventuel), mais ces deux informations restent conceptuellement différentes, et il n’y a donc pas de problème à garder la seconde dans un silo étanche, hors de portée de l’attributeur.

Conclusion

Ce ne sont pas les silos qui posent problème en soi. Comme dit Hank Marquis, l’étanchéité et la claire séparation des responsabilités sont des points importants. Le problème apparait lorsque les silos doivent communiquer. La première approche, trop rustique, consistant à détruire les silos, revient à jeter le bébé (la séparation des responsabilités) avec l’eau du bain (la difficulté à faire interopérer). Il faut, pour garder les deux avantages, faire l’effort de contractualiser les échanges entre les silos. Ainsi, chacun reste indépendant, tout en évitant la duplication de données qui est un problème aussi important que le manque de séparation claire des responsabilités.

Au final, si vous êtes architecte SI, ne vous imaginez pas qu’une architecture SOA relève de la technique et des services web ou de la conception technique d’API. Au contraire, votre travail principal pour atteindre une architecture de services propres est de travailler sur les contrats d’interopération. Pour cela, les normes (iCal, vCard, ebXML, CMIS, et des centaines d’autres) sont à votre disposition et en leur absence, votre boulot principal est de décrire précisément le métier ainsi que de contractualiser sa représentation technique, à savoir un format qui servira de pivot dans tous le SI.

Votre meilleur allié pour cette tâche de conceptualisation et de standardisation est l’approche Domain Driven Design avec son concept de Bounded Context, et en particulier le bouquin fondamental d’Evans.

Un bonus, et une question

Un cadeau pour finir : la vidéo de la présentation de DDD par Eric Evans sur InfoQ. Et une question pour alimenter le débat (et les commentaires) : pour vous, la notion de Bounded Context est-elle assimilable à celle de silo dans le cas d’une architecture microservices, où tous les silos ont été découpés au maximum du raisonnable pour le métier ?

Posted in Uncategorized | Tagged | Leave a comment

Du NLP au programme, vraiment ?

Un retour sur un article qui m’a fait réagir : http://tcz.hu/the-future-of-programmers

L’idée est en gros de dire que la prochaine révolution industrielle va supprimer les métiers de docteurs et de conducteurs de véhicules, et que nous autres programmeurs seront les prochains, mais que nous aurons l’honneur de participer à cette destruction de métier en créant les logiciels qui vont nous remplacer.

L’auteur utilise ensuite comme illustration de son propos le fait qu’un programme est désormais capable d’analyser une règle métier écrite en texte, et de décomposer ce langage naturel en une arborescence de sujets, de conditions et d’actions. Il utilise pour cela un excellent exemple graphique, que je me permets de recopier de son article (source citée plus haut) :

nlp2.png

Jusque là, on est dans de la démonstration logique. Mais le saut à la conclusion est un peu abrupt : “How difficult is it to translate this into a computer program now?”. Ben, justement… c’est ça qui est difficile, et pas le reste. Parce que découper un texte correctement formaté en atomes reconnaissables et appliquer des actions dessus, c’est ce que font les moteurs de règles depuis 15 ans déjà !

Or, ce qui fait un “programme”, c’est justement tout ce qu’il y a autour et qui est incommensurablement plus difficile :

  • Tenir compte des règles non exprimées (tout client d’un éditeur de logiciel commence toujours par lui dire que son métier est simple… jusqu’à ce qu’on l’analyse ensemble et qu’il réalise que son métier est complexe, et qu’il ne lui apparait comme simple que parce que son expérience fait qu’il réalise inconsciemment 90% des tâches).
  • Tenir compte de règles floues.
  • Réfléchir au parcours ergonomique pour les utilisateurs.
  • Savoir régler les problèmes indirectement liés au programme : robustesse, sécurité, performance, etc.
  • Penser en termes holistiques, c’est-à-dire pas seulement au programme en lui-même comme silo étanche, mais en tant que bloc communiquant d’un Système d’Information. La valeur est désormais plus dans les interconnexions que dans les atomes du SI.

Au passage, c’est d’ailleurs pour cela qu’il est incomplet que dire que la data vaut de l’or : tant qu’elle reste dans son programme d’origine, elle n’en a pas, et n’en acquiert que lorsqu’elle est partagée, d’où l’importance économique de l’Open Data. Vous ne croyiez tout de même pas que l’Etat publiait de la donnée ouverte juste pour des raisons de transparence envers les citoyens ? Sourire

Bref, quand on me montrera un programme qui est capable d’analyser les conversations d’un comité de vingt personnes et d’en sortir une norme de communication informatique qui traite tous les cas d’usage évoqués, je reconnaitrai que le métier de développeur est mort. Mais je pense que je le serai bien avant…

Posted in Retours | Leave a comment

Hackathon ENI sur la sécurité

C’est suffisamment rare pour être souligné : un hackathon sur la sécurité. Si vous vous sentez des compétences de Ethical Hacking, l’ENI organise un hackathon sur le sujet les 29 et 30 septembre.

Détails et inscription sur http://www.editions-eni.fr/hackathon

image

Si le sujet ne suffit pas à vous motiver… le 1er du classement remportera plus de 7000€ de lots !

Posted in Uncategorized | Tagged | Leave a comment

Java, encore et toujours après la bataille

.NET a beau être né dix ans après Java, il reste depuis la version 2.0 systématiquement en avance sur lui. La gestion des lambda, les classes anonymes, la programmation fonctionnelle, les tâches, les délégués, etc. : à part l’injection de dépendances, il n’y avait pas un domaine du langage où .NET ne démontrait sa suprématie (bon, OK, j’exagère peut-être un peu juste pour taquiner Nico Sourire). Et encore, l’injection de dépendances avait tellement été mise à toutes les sauces avec Spring qu’il fallait presque faire une injection pour ajouter deux entiers.

Un article sur InfoWorld en date du 11 septembre 2015 annonce un effort d’Oracle pour rendre plus simple la gestion des dépendances et de la modularité en Java, et cet article entre en résonnance avec les multiples problèmes que je vois professionnellement autour de la gestion du CLASSPATH ainsi que des conteneurs OSGI. Tous ces problèmes sont réglés depuis longtemps en .NET grâce à NuGet, qui fait même désormais partie intégrante du nouveau SDK Core .NET.

Si l’on ajoute à ça que, de toute façon, avec l’avènement des conteneurs et des architectures à microservices, la modularité est désormais hissée au niveau du service lui-même (ce qui est le niveau de granularité idéal), on se rend compte qu’Oracle est encore en train d’apporter une solution avec Jigsaw à un problème qui n’en est désormais plus un. L’inconvénient d’avoir une gouvernance qui avance à la vitesse d’un escargot rhumatisant…

Pendant ce temps, du côté .NET, ça avance sur l’asynchronisme à tous les niveaux, les TypeProviders en F#, la compilation native, la structure modulaire non pas des dépendances mais carrément de la runtime, le calcul parallèle, etc. Java garde une tête d’avance pour ce qui est du nombre de projets utilisateurs, mais pour ce qui est de la richesse fonctionnelle, il y a du boulot pour rattraper .NET. Et il ne fait que peu de doute que le second critère est plus important que le premier.

Posted in Uncategorized | Tagged | Leave a comment

La roue tourne…

Assez drôle de voir qu’après tant d’années à moquer la concurrence, Apple se retrouve aujourd’hui à sortir un iPad Pro en réaction au succès grandissant de la Surface de Microsoft…

Et le coup du stylet désormais vanté après avoir été voué aux gémonies, rétrospectivement, ça fait quand même pas mal rire Sourire

Permalien de l'image intégrée

Posted in Uncategorized | 2 Comments

Hard Code d’Eric Brechner en français !

Ca y est : après des mois et des mois de problèmes administratifs, et donc plus d’un an après avoir fini de le traduire, le livre d’Eric Brechner traduit en français par mes soins est ENFIN disponible à la vente sur le site de Microsoft Press. La page n’est pas très explicite, car la couverture montrée est celle de la version originale, mais c’est bien la version française que vous y trouverez.

image

Eric Brechner est un manager de Microsoft dont la liberté de ton est reconnue et qui nous gratifie tous les mois d’un édito de grande qualité sur la façon de gérer une équipe informatique, sur son blog http://blogs.msdn.com/b/eric_brechner/.

Il se trouve que je suis tombé sur ce livre au moment où les besoins de mon entreprise ont fait que j’ai dû rajouter une corde “management” à mon arc, en plus de celle d’architecte logiciel. Et il s’est révélé une véritable mine. J’ai lu une bonne quinzaine d’autres livres sur le sujet, mais presque tous se trouvent résumés dans quelques articles de blogs d’Eric Brechner. Aujourd’hui, je me rends souvent compte que la façon dont je gère mon équipe est fortement influencée par telle ou telle expérience développée par Eric.

La quatrième de couverture, pour vous donner envie Sourire :

image

Enfin, un grand merci à mes relecteurs Clémence Chanel, Guillaume Collic et Olivier Dupont !

Et pour acheter (35,99 $), c’est ici : https://www.microsoftpressstore.com/store/i.m.-wrights-hard-code-a-decade-of-hard-won-lessons-9781509301201

Bonne lecture !

Posted in Veille | Tagged | 2 Comments