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

Livre sur Docker en approche

Mon dernier livre va bientôt être publié chez l’ENI. Le sujet est Docker et les microservices. J’ai essayé de faire un livre très pratique sur Docker, orienté développeurs, en montrant comment on peut créer une architecture de microservices où chaque service est contenu dans une image Docker, en faisant exprès d’utiliser plusieurs technos, pour montrer un peu toutes les astuces : JEE, .NET Core, Python et Node.JS sont au programme !

L’idée est de montrer une application de gestion de l’optimisation d’un emprunt, avec une interface, une persistance, un scheduler d’optimisation, un module d’optimisation d’emprunt, et un module de calcul parallélisable avec lien asynchrone. Tout ça est créé en mode microservices et avec des API pour montrer une architecture correctement urbanisée, qui est la cible idéale des développements Docker.

Rendez-vous sur le site des Editions ENI pour tous les détails… et les pré-commandes (Daddy needs an EV3) Sourire

image

Posted in Uncategorized | Tagged | Leave a comment

.NET sur Linux dans Docker sur cluster CoreOS dans Azure

Ca y est : la vidéo de notre session au TechDays avec Guillaume Collic est en ligne, sur https://techdays.microsoft.fr/programmes/2015/fiche-session.aspx?ID=50a5208e-fa8c-4dd1-a0bd-88a9a46577c6. Vous pouvez donc retrouver l’explication détaillée sur comment faire du .NET sur Linux de manière supportée par Microsoft dans un conteneur Docker, puis comment utiliser Azure pour monter un cluster de CoreOS dans lequel vous déploierez vos images Docker en mode load-balancé.

Le contenu est le même sur YouTube : https://www.youtube.com/watch?v=eY2l6c0cjZ4

image

Posted in Retours | Tagged | Leave a comment

ReBUILD : ça arrive bientôt !

Le 1er Octobre 2015, c’est l’évènement ReBUILD à Nantes Sourire

image

J’aurai le grand plaisir d’y présenter une conférence intitulée “Docker : déployer du .NET dans des micro-conteneurs isolés sous Linux et bientôt Windows”. Avec un peu de bol, ça tombera en même temps que la sortie de mon nouveau bouquin, justement sur Docker, aux Editions ENI comme souvent. Si vous vous demandez comment mettre en œuvre une architecture de micro-services avec Docker, je vous engage à jeter un coup d’œil sur ceci.

Pour ReBUILD, les préinscriptions sont ici.

Posted in Retours | Tagged | Leave a comment

L’agilité expliquée à mon banquier…

Des fois, c’est une bonne pratique d’essayer d’adopter un point de vue complètement différent, et le vocabulaire associé, pour mieux comprendre des concepts qu’on est (à peu près) capable d’expliquer avec son dialecte habituel. Du coup, au lieu de rester dans mon jargon informatique, je vais essayer d’expliquer l’agilité en termes financiers.

L’agilité – par rapport au traditionnel cycle en V où on conçoit quelque chose, puis on le fabrique, puis on le teste, puis on le vend – consiste à fournir un produit sous forme de petits incréments qui apportent de la valeur à chaque fois. Par exemple, un robot ménager avec dans un premier temps juste le moteur, le bol standard et le hachoir, qui est l’outil le plus utilisé. Ensuite, on pourra ajouter un blender pour la soupe, un autre outil pour râper, un autre pour faire des tranches, etc.

L’avantage est que l’investissement initial en R&D, production, stockage, vente et autres activités est alors moins élevé. Du coup, le retour sur investissement arrive beaucoup plus tôt :

image

Comment réussir à atteindre cet état financier enviable ? La solution principale a été rapidement abordée, à savoir réaliser des petits incréments. Mais imaginons maintenant que le robot soit vendu sans moteur, et que nous ayons ajouté les râpes, le blender et tout le bazar, mais toujours pas le moteur. Bref, le robot n’aurait que très peu de valeur pour un potentiel utilisateur. C’est pour cela que nous sommes plutôt parti d’une version minimale mais fonctionnelle, et que nous avons progressivement ajouté des items dont la valeur était moindre. L’idée de l’agilité et du Lean est de commencer systématiquement par les fonctionnalités qui ont le plus de valeur.

Dit comme ça, on pourrait se demander pourquoi ces idiots d’informaticiens (j’en suis) ne commencent pas par les fonctionnalités de plus haute valeur. Il se trouve que le métier étant relativement récent (quelques dizaines d’années, ce qui n’a pas permis une industrialisation pour l’instant), les équipes ont tendance à souvent réinventer la roue et mettre en place des fonctionnalités “de base” mais qui n’ont pas de valeur immédiate, avant de travailler sur le métier, puis seulement en fin de projet mettre en place une interface graphique pour piloter le tout. Or, le client a besoin de l’interface graphique. En fait, il ne voit même que ça et le reste est pour lui du blabla pur et simple…

Pour résumer, l’idée de l’agilité est de mettre le plus possible de valeur dans le produit en amont. Typiquement, là où dans une approche traditionnelle, peu de fonctionnalités sont accessibles à l’utilisateur (20% après consommation de 80% du budget), l’approche agile permet l’inverse du Pareto (80% de la valeur après avoir consommé 20% du budget). Il arrive d’ailleurs assez souvent en mode agile que le projet s’arrête avant la fin de la consommation du budget, car quasiment toute la valeur est atteinte. Si le projet est bien tenu, seules des fonctionnalités peu importantes restent à réaliser, et parfois le client préfère garder son reliquat de budget pour autre chose.

image

Si jamais des financiers lisent mon blog, je serais heureux de recueillir leur retour pour savoir si j’ai réussi à leur expliquer l’agilité Sourire.

Posted in Agile | Tagged | Leave a comment

Agile Vendée 2015

Sur mon retour du BreizhCamp, je disais que j’étais un peu triste de ne pas avoir pu assister à toutes les journées, mais finalement j’ai passé une journée aussi géniale à la première édition d’Agile Vendée, qui – pour une première – était un coup de maître. Du coup, le seul regret était que deux conférences aussi excellentes soient en même temps…

Quelques notes et commentaires un peu bruts de fonderie sur ce que j’ai vu et entendu.

Construire un projet de territoire

C’est avec des sujets comme ceux-là (mais aussi beaucoup des autres proposés sur cette journée) qu’on sent que l’agilité est enfin sortie de l’informatique, et commence à prendre ses marques sur les autres domaines. Intéressant d’aller voir un projet de territoire, car c’est plutôt mes clients qui sont concernés par cette partie, mais du coup, ça me permet de mieux comprendre quel est leur métier en vrai, quels sont leurs enjeux, etc.

Et les retours ont été à la hauteur de mes espérances. Non seulement j’ai mieux compris la façon dont les collectivités géraient leur stratégie, mais en plus je suis ressorti avec des astuces pratiques sur la conduite de changement, etc.

Territoire de 83 communes, juste au bord de la CA de Strasbourg. Schéma de Cohésion Territorial, Fortes disparités à l’intérieur de ce territoire. Tourisme comme second pôle économique de ce territoire. Premier moteur : l’industrie, avec les grandes entreprises pour 34% de l’emploi local. Discours comme quoi la richesse part à Strasbourg

Leur questionnement principal est sur l’horizon à 20 ans, car ce ne sont pas les grosses entreprises qui vont porter la croissance dans les 15 ans à venir

Méthode du marketing territorial pour l’instant surtout utilisé par des gros ensembles, mais eux l’appliquent aussi. Le principe principal : se distinguer de ses voisins. La Bretagne et l’Auvergne, ainsi que la marque Alsace, ont mis en œuvre cette méthode. New deal de l’Auvergne : ils paient trois mois de loyer, trouvent l’école pour les enfants et le boulot pour le conjoint, en mettant volontairement en avant le fait qu’il n’y a pas trop d’activité et que les gens auront du calme.

Premier travail de synthèse de tous les diagnostics (INSEE, CG, Ville, etc.) dans 26 fiches de « réalité du territoire », puis demande aux élus et partenaires de dire lesquelles portaient le plus la richesse du territoire. De là ont été proposées trois stratégies : PME en réseau, PME export, tourisme. Ensuite, réunion avec trois stands ayant creusé les trois stratégies en mode prospectif. Avec un seul billet à mettre dans une urne pour forcer à se positionner sur un seul sujet. La première a été choisie à 80% : amener les PME ensemble vers l’innovation

Etape suivante = atelier d’objectifs. Puis, implication des PME dans le projet en les inventant dès le choix réalisé. On leur a demandé de quoi ils avaient besoin pour innover, et proposer nous des actions, sans limite de créativité. Puis priorisation des actions : seulement avec des personnes volontaires, mais un mélange de leurs types

Après, il restait quatre mois sur l’année prévue, donc il fallait trois actions rapides :

  • Speed meeting des réseaux : faire se rencontrer 17 réseaux + les entreprises
  • Visite de l’école du LEAN (avec une mini-usine où on voit en vrai les principes) à l’ECAM Strasbourg
  • Visites d’entreprises croisées

Avec les autres organismes, principe de ne surtout pas refaire ce qui est déjà fait (aide à l’innovation, etc.), mais de mettre en valeur les programmes existants. Filtrage dès le début, à la première réunion, des réfractaires : à la seconde, il n’y avait que ceux qui étaient porteurs. Par contre, le groupe restait ouvert à ceux qui voulaient se rajouter.

Pour ne pas rajouter une couche au millefeuilles, ils se sont posés en orientateurs dans les couches. Outils d’évaluation uniquement au terme des actions. Création d’un noyau dur sous forme de comité de pilotage, pour garder le mouvement dans le temps. Pérennisation par une communauté en ligne. Approche pour éviter la compétition sur le même sujet avec les pays à côté.

De la culture projet à la culture produit

Présentation très dynamique, avec deux personnes qui exposaient le avant / après. J’ai juste eu un peu de mal à suivre comment les chiffres étaient comparés, mais je pense que c’était sur plusieurs projets / produits qu’ils ont réussi à avoir des stats. Au final, c’était très intéressant d’avoir un REX avec la personne qui avait mis en place l’agilité et le coach qui l’a aidée, plutôt qu’une ou l’autre séparément.

Sur les définitions, projet = démarche tandis que produit = résultat.

Dans le produit, élément majeur = la vision, qui devient le cadre partagé.

Remplacer les démos aux parties prenantes par des revues testables par les utilisateurs finaux (c’est vrai qu’on a souvent tendance à se réfugier derrière une démo, avec nous qui manipulons, plutôt que laisser les utilisateurs finaux prendre en main).

Un produit émergent plutôt que le suivi d’un plan.

Banque Populaire Atlantique

Jeu « remember the future »

Site de dépôt d’idées et de vote. Ils appellent cela le laboratoire d’idée, et ça pourrait faire un bon sujet pour des exercices d’urbanisation de services, ainsi que pour pratiquer différents langages pour les différents services : persistance, récolte, stats, etc.

Transformation digitale indissociable de transformation agile (on ne peut pas séparer les outils des hommes – un peu comme le fait que le processus peut être le plus proche représentant de l’individu dans le SI)

Reviennent sur l’importance central d’un sponsor. Chez eux, le DG qui a financé le groupe agile.

La laboratoire d’idée a commencé uniquement sur les managers, mais la seconde thématique a été ouverte sur tout le monde.

Au lieu d’avoir une grand messe pour les sociétaires, ils font des comités pour produire des idées.

1, 2, N projet en agile

Un projet seul, on fait tout bien comme il faut. N projets, ce n’est plus du tout la même chose. L’interlocuteur est alors le CODIR sur des EPIC, et plus l’équipe sur une feature.

Important d’évacuer dès le début l’idée de changer toute l’entreprise en agile.

Caroline Damour est Product Owner (je n’ai pas saisi le nom de la société). Elle présente le point de vue d’une gestionnaire de portfolio de projets agiles.

Bénédicte Taillebois est responsable Etudes DSI d’Astria, et a fait un changement complet d’un SI bloqué (intéressant pour l’urbanisation).

Avant tout établir un consensus dans lequel on va trouver l’ordre pour réaliser les projets dans leurs différentes phases, en finissant bien, et en évacuant éventuellement ce qui peut être simplement abandonné. Il faut donc une vision stratégique pour savoir comment prioriser ces projets agiles.

Atelier Reservoir Dogs de Thomas Lissajoux (coût du délai en X, stratégie en Y et classement en 3×3 boîtes)

Conclusion qu’il faut cartographier et se donner les moyens de prioriser rapidement. Discussion avec tous les PO qui discutaient pour savoir quels sont les projets prioritaires (une bonne pratique). Conclusion claire sur le fait que certains projets dégageaient.

Astria : la moitié du SI à casser et il faut rester opérationnel

  • Architecture de services et de référentiels
  • Nettoyage de la donnée
  • Mises en production successives

Ils ont fait une story-map de SI, et ont vu tout ce qui avait été oublié. Rester adaptable aux contraintes changeantes du monde réglementaire externe et de la concurrence. Donc plan modulaire.

Les méthodes agiles rendent plus difficile le travail du métier (j’ai déjà entendu ça Sourire) car ils doivent réfléchir à ce dont ils ont besoin en priorité, entre autres. Pour les aider, la DSI a fait une roadmap avec quelle équipe ferait quoi quand.

Livre Impact Mapping cité sur cette conférence comme sur une précédente : A VOIR

Innovation game BUY A FEATURE peut être intéressant pour nos POs en priorisation aussi. Implication de l’équipe produit en leur donnant la responsabilité de la quotation, en leur laissant faire un mercato des recrutements, et en apportant leur vision dans les ateliers métier. Le mercato est une feuille sur laquelle ils peuvent se mettre sur leur projet de préférence. Le portfolio de pilotage stratégique est aussi partagé au niveau de l’équipe, pas que pour la lecture, mais aussi pour la participation.

Entretien du portfolio de projets : plus c’est difficile, plus il faut le faire souvent. Le suivi régulier permet de valider qu’on est toujours bien aligné sur la vision. Ca doit être intéressant de le faire à partir de la cartographie de services, en faisant une carto à six mois, par exemple.

Se servir du portfolio passé pour améliorer la prédicatibilité. Les temps passés, c’est une corvée, mais si on s’en sert pour faire de meilleures évaluations de projets, ça vaut le coup.

Le point important est de savoir décider vite : ne pas avoir juste le chef, avoir un vrai processus de délégation, un processus de décision très rapide et pas avec des signatures papier, etc. Passer du plan (figé) à la carte (domaine des possibles)

Manque reconnu sur le fait qu’il n’y avait personne dans le portfolio pour représenter le projet de la DSI (par exemple, suppression de la dette technique, etc.) : « la DSI est un client comme un autre ». Par exemple, industrialiser le développement, ça prend du temps.

Une amélioration pourrait être de ne pas avoir une personne gestionnaire du portfolio. Et surtout que ce soit les métiers qui discutent, et pas la DSI qui doive tout le temps arbitrer.

Intérêt de travailler avec des contrôleurs de gestion, car ils connaissent bien la notion de valeur et de coût.

Bien définir les critères de succès pour qu’on ne dise plus qu’un logiciel n’est pas fini car il ne gère pas 100% des cas particuliers, qui n’étaient parfois même pas prévus dans la backlog.

Et le mot de la fin pour Bénédicte Taillebois : « Tant qu’il n’y a pas de courage, il n’y a pas de méthode qui marche ». C’était dit d’une manière tellement ressentie et évidente qu’on sent bien qu’on est au plus profond de la méthode agile.

Conclusion

A voir toutes ces personnes qui veulent changer leur façon de faire, et à entendre Bénédicte Taillebois remettre au centre de sa conférence la valeur fondamentale de l’agilité qu’est le courage, je me dis que c’est finalement ça qui est le critère qui rapproche tous ces agilistes : le courage de changer. Pour eux, le changement est une façon de vivre, la réaction à une modification de la situation un stimulus pour évoluer.

Posted in Agile, Retours | Tagged | 2 Comments

Retours sur le BreizhCamp 2015

Toujours aussi déjanté, toujours aussi passionnant, toujours aussi diversifié… le BreizhCamp, bien sûr ! Quelques retours sur les conférences de cette édition qui a encore une fois tenu ses promesses. C’est de la note brute, que chacun y trouve ce qui lui plait. Et ça ne concerne que le second jour, je n’ai pas pu aller aux autres sessions. Snif…

Keynote jour 2

Une première partie par un intervenant d’OVH, qui utilisait une métaphore sympa sur le Mont Saint Michel pour parler de réduction des goulets d’étranglement.

La seconde partie par la fondatrice de la startup B Sensory. Passionnante car passionnée elle-même, et c’est bien d’entendre parler du pouvoir de la littérature dans une assemblée de geeks. Et je dois dire que pour le sujet (littérature érotique + objet connecté vibrant), je trouve que nous avons bien démenti notre réputation de lourdeaux ! Enfin, perso, c’est l’impression que j’ai eue…

Docker en production

Plein d’excellents conseils avancés sur Docker. Et Nico avait enlevé son costard orange, donc on pouvait ouvrir les yeux sans se les brûler Sourire

–net = host excellent pour la performance, mais on perd par contre en isolation, car les conteneurs sont tous reliés en passant par la machine hôte.

Pour contrer les limites réseau de Docker, en attendant qu’elles soient résolues dans Docker lui-même (peut-être), quelques solutions : OpenVSwitch, Weave (mais vu comme un hack pourri par les conférenciers) et libNetwork (ex-SocketPlane) = VXLan seulement, mais pas sécurisé.

Question perso : est-ce qu’à un certain degré de complexité (en particulier quand on veut échanger entre deux hébergeurs), on ne ferait pas mieux de simplement revenir à la couche de niveau supérieur HTTP et échanger comme si les différents services exposés par Docker étaient carrément des services extérieurs ?

Citation de https://www.seancassidy.me/dont-pipe-to-your-shell.html pour expliquer à quel point faire un pipe d’un fichier téléchargé dans un shell pour installer quelque chose est dangereux, y compris après vérification du script, s’il y a interruption du chargement.

BUILDON trigger pour que les images soient rebuildées lorsque les images de base sont changées, de façon que l’image soit toujours sur une image Ubuntu bien patchée à jour. Et dans tous les cas, il faut rebuilder souvent pour cela.

Attention à la fasse sécurité du groupe Docker, car les droits sont équivalents à root. Et sur le point de vue de la sécurité, prendre les précautions sur le démon, car il n’a pas TLS d’activé par défaut.

IPS : certains peuvent avoir des soucis à valider la non-altération des images, qui sont en lecture seule. De plus, la présence d’un agent va à l’encontre de la philosophie de processus unique dans Docker (perso, l’exception sur des processus annexes ou utilitaires me parait tout à fait bénigne…)

Sur Docker, pas de live migration ni de fault tolerance, donc toujours intéressant de garder une couche de vraie virtualisation.

Si on veut passer en mode 100% conteneur, il faut changer de point de vue et passer en mode de pensée “conteneur éphémère”, stateless.

Attention au Single Point Of Failure que constituent le registre, l’annuaire et l’orchestration, domaines sur lesquels les outils ne sont pas encore mûrs.

Le load balancing peut se faire au niveau HTTP avec libNetworks.

Manque d’outillage à ce jour pour le tuning, et les conférenciers s’interrogent sur la capacité réelle des cgroups à limiter les impacts inter-conteneurs (CPU, RAM, I/O).

Attention, le bridge network fait perdre en performance. Par contre, sur de la production, il faut brancher le conteneur Docker directement sur la carte réseau.

Pour ce qui est de la supervision, une approche est de mettre un agent de supervision sur le host (et au passage, ne pas oublier de superviser le démon Docker lui-même) de type nagios-docker ou sensu (qui doivent faire du docker exec, mais ne sont pas présents sur le conteneur lui-même). Et sinon, docker stats donne déjà pas mal de contenu.

Pour les logs, pas de syslog dans le conteneur pour respecter le principe du processus unique (j’ai déjà dit ce que je pensais de cette règle). Eventuellement, ce qui peut être fait est d’envoyer sur le syslog de l’hôte. Logstash est plus récent que syslog et à favoriser. Bien penser à l’asynchronisme pour les forts volumes de façon à ne pas impacter la performance (je pensais que c’était le cas par défaut). Donc, par exemple, pousser dans un volume et paramétrer Logstash pour qu’il vienne dedans pour consommer la donnée.

Bonne pratiques : utiliser les variables d’environnement, le service discovery et le pattern Ambassador.

–add-host à regarder.

Pour ce qui est du backup, se servir du fait que les couches sont partagées et en lecture seule peut faire gagner énormément de place.

 

Security matters (quick talk)

Intéressant d’analyser la liste des autorités de certification racines dans les navigateurs. Il y en aurait un relié à l’armée turque. Ca vaudrait aussi le coup de comparer les navigateurs entre eux de ce point de vue.

Ce qu’on appelle les Extended Validation Certificates sont ceux qui apparaissent avec un nom long dans la barre d’adresse URL des browsers. Ils ne sont pas techniquement plus sûrs, mais la présence d’un nom en lien validé avec le domaine est quand même un plus.

Let’s encrypt est un projet de génération d’autorités de certificats gratuites, qui fonctionne en automatisant la validation de l’identité du demandeur en lui demandant d’installer un callback sur son propre site pour valider qu’il en est le propriétaire. Pas bête comme idée pour shunter toute la partie de validation physique que font les autorités traditionnelles avec le numéro de SIRET, etc.

Rust

Christophe Augier (@tytouf) de WindRiver présente. Super intéressant même si on n’a pas nécessairement le besoin souvent de travailler avec ce genre d’outils. Et le conférencier avait bien préparé et était pédagogue donc on ressort avec une bonne compréhension des concepts. En une heure, je me sens plus capable de m’attaquer à la doc ou de lire un bout de code et de comprendre à peu près ce qu’il fait et sa syntaxe.

Rust = langage de programmation orienté système, mais qui élimine les segfaults et garantit la sûreté du threading. Binding pour s’accrocher sur du code legacy en C ou autre. Plus de 10 ans de développement derrière ce langage, et la version 1.0 sortie le 15 mai 2015.

Orientation des RFC par la communauté (comme Python avec les PEP) : open governance en plus de open source. Compilateur LLVM. Rust utilisé pour Servo, le moteur de navigateur web multithreadé poussé par Mozilla, qui est à l’origine de Rust. Crates.IO pour la gestion des dépendances et des packages (outil Cargo équivalent à NPM). Caractères directement en Unicode.

La règle de nommage des structures (et bien sûr pour d’autres entités) est vérifiée directement par le compilateur.

Les énumérations permettent de définir différents types qui demanderont chacun des ensembles de types différents. Par exemple, une figure peut être de type Cercle (point, rayon) ou de type Carre (cote).

Inutile de déclarer la fonction avant de l’utiliser comme on est obligé de faire en C, même si c’est navrant, de l’aveu même de l’orateur.

Contrôle / Simplicité / Sûreté ne peuvent pas être tous présents dans la gestion de la mémoire. Rust sacrifie surtout le second critère.

Box::new = affectation sur le tas mémoire.

Si personne n’a plus l’ownership sur une box mémoire, on peut la désallouer.

Il ne peut y avoir qu’un seul propriétaire pour la variable. Si on affecte une valeur sur une autre variable, ça plante dès la compilation (« use  of moved value »). Même chose si une fonction utilise une variable qu’on lui a passée : elle prend alors possession de la variable, et donc si on appelle deux fois à la suite la même fonction, le compilateur plante. Evite d’avoir plein de pointeurs sur la même zone mémoire. Pour les types primitifs, pas de problème, car il y a alors copie de la valeur. Pour régler ce souci, on peut faire en sorte que la fonction renvoie la possession de la variable qui lui a été passée. Mais le plus simple est d’utiliser la fonction de borrowing, avec une référence qui permet d’emprunter la ressource (symbole &). Par contre, les références sont immuables pour sécuriser le contenu. Si on souhaite les changer, il faut rajouter &mut au lieu de & seul. La sûreté est gérée par le fait qu’on ne peut avoir qu’une seule référence muable.

Le compilateur vérifie également qu’on référence des objets qui ont au moins le cycle de vie de la référence. Sinon, il dit que la durée de vie de l’objet n’est pas assez longue, au lieu de risquer un problème à la runtime où on pointerait sur un espace mémoire abandonné, et potentiellement utilisé depuis pour autre chose. On peut faire du référence counting avec clone(), comme les smart pointers en C++ (ça ne clone pas la valeur, il y a bien une seule utilisation mémoire, mais ça permet de compter, et donc de purger quand il n’y a plus de clone).

Pour la gestion de la concurrence entre thread, c’est pratique, car Rust ne donne pas un pointeur sur lequel tout le monde peut lire ou écrire, mais compte le nombre de références et permet d’être explicite sur l’autorisation de mutable (qui ne peut être donnée qu’une fois) ou sur la copie de lecture (qui évite les phantom reads, puisqu’il s’agit d’une copie).

Les interfaces sont remplacées par des traits, qui peuvent être ajoutés directement sur les types, sans obliger à hériter une nouvelle classe. On peut par exemple surcharger un entier. Le trait send et le trait sink permettent de partager la donnée de manière sûre entre les threads. Mutex implémente le trait send, et Arc fait de la référence counting atomique entre les threads, et donc gère quant à lui le partage. Dans le code, on fait ensuite un lock pour bloquer le Mutex et un unwrap pour sortir la donnée. Le lock sera automatiquement relâché au moment où on va sortir de la portée.

On peut utiliser la notion de channel, qui force à avoir un send() et un recv(). Pour échanger de la donnée. Au final, Rust va libérer la mémoire pour nous, mais sans GC : c’est juste qu’il analyse – avec l’aide du développeur – la façon dont la mémoire est utilisée. Il empêche la modification de ressources pendant l’utilisation, ainsi que l’accès à de la mémoire qui n’est plus utilisé. Ce mode est d’ailleurs utilisé pour tout type de ressource, et pas seulement la mémoire. Il y a par exemple un trait drop qui fait un peu comme dipose, et qui peut être utilisé pour libérer un fichier dès qu’on a fini la fonction qui l’utilisait.

Pattern Option<T> = Some<T>, None comme dans F# pour éviter de devoir gérer des null. Même chose pour les exceptions qui n’existent pas en Rust, et sont remplacées par une Option<> = Res<T>, Err<U>. Rust fait également du pattern matching sur les types complexes, dits énumérations. Il y a aussi un système de closures, donc on est partis d’un langage proche du système, mais en fait on retombe sur une formulation et des capacités très proches des langages fonctionnels.

Il y a également des macros embarquées (symbole « ! »). Permet de faire de la métaprogrammation.

ASP.NET V5

Notre conférence, en co-présentation avec Benjamin Talmard de Microsoft. Le but était de montrer la simplicité de la nouvelle version d’ASP.NET V5, surtout en lien avec .NET Core. On peut désormais créer un service REST en quelques lignes de code seulement, avec un éditeur de texte au lieu de Visual Studio, un chargement dynamique des dépendances et une exécution dans une CLR modulaire. NodeJS n’a qu’à bien se tenir !

L’exemple utilisé pour la dernière démo est sur https://github.com/jp-gouigoux/mathapi

Rest Groovy

Compte gratuit possible sur APISpark.

Commence par retour sur les principes énoncés par Roy Fielding. Hypermedia As The Engine Of Application State = Hypermedia APIs, HAL, JSON-LD, Siren, etc.

HTTP Status Dogs pour faire apprendre les status codes de manière amusante.

gServ pour exposer de l’API en Groovy. Ratpack est utilisable en Groovy mais aussi en Java. Il permet de créer des délégations entre les handlers. Restlet Framework permet d’exposer, mais aussi de consommer du REST. L’annotation @Grab(nom du fichier) récupère automatiquement les dépendances. Utilisation aussi de @GrabResolver pour donner le serveur sur lequel faire le Grab.

Pour le client depuis un navigateur : Restangular (va au-delà de la pile REST d’Angular) / Restful.js (indépendante de tout FW JavaScript) / autre pour faire de la consommation côté client. Et pour le client depuis un serveur : wslite, etc.

‘http://starwars.apispark.net/v1/people/1’.toURL().text : fait l’appel, car Groovy peut décorer une chaîne avec sa fonction ! Par contre, l’API bloque son UserAgent par défaut, et il faut changer le requestProperties.

Attention, l’URL ci-dessus ne marchait pas (peut-être juste manquait-il HTTPS) et il semblerait que ce soit plutôt quelque chose comme swapi.co/api/planets/1. (avec starships, vehicles, films, etc. comme collections, mais la racine /api donne la liste). DJANGO permet de montrer l’API de manière propre sur l’appel (pas tout à fait le même type d’outil que Swagger, mais un facilitateur également).

httpie est une sorte de curl amélioré qui formate correctement le JSON affiché en retour, fait du pretty-print en couleurs, etc. Postman est capable dans sa version 3 de prendre une définition Swagger en entrée.

Debogage de JavaScript

Alert remplacée par console.log (et on peut mettre dedans un objet, un bout de DOM, etc.)

Console.trace (ne génère pas d’erreur)

Console.count pour les compteurs

Console.table pour afficher les propriétés sous forme de tableau (on peut passer une seconde propriété qui est la liste des colonnes qu’on veut voir lorsque les objets sont trop gros).

Note : IE8 n’active la console que si les outils de dév sont actifs.

Break on subtree modification sur un breakpoint : va s’arrêter sur le code qui modifie le bout de DOM donné.

La case à cocher Async dans la stack trace permet de remonter jusqu’au code depuis lequel le lancement de la commande asynchrone avait été faite.

Simuler la latence du réseau : fonction dans les outils mobiles (deuxième icone en haut à droite dans les outils de développement de Chrome) qui permet de changer le type de réseau.

Snippet permettant de glisser des propriétés devant les champs, de façon à pouvoir tracer les accès en lecture et/ou en écriture sur un attribut donné : debugAccess(l’objet, ‘la propriété’)

Angular.element($0).scope() permet d’accéder aux controleurs Angular.

Node-inspector

Github.com/jollivetc pour récupérer quelques outils.

Push & JSONPatch

Cédric Tran-Xuan de StreamData.IO présente.

Nouvelles technologies ~ 100 centrales nucléaires en 2015. QCon London : retour d’un ingé Google expliquant qu’une réduction de 5% de la consommation a permis d’éviter la construction d’un datacenter.

Applications de plus en plus en « temps réel », dont avec énormément de pull, même s’il n’y a rien de changé => plus performant de passer au push, pour ne pousser que lorsque c’est nécessaire, voir diffuser en triangle pour économiser en descendant.

On peut gagner aussi beaucoup de temps en faisant de l’incrémental. JSON-Patch, RFC 6902, permet de définir la mise à jour d’un document JSON. A croiser avec l’intérêt de faire un PUT uniquement de la propriété voulue sur un tiers : 1) il y a une norme pour ça, et 2) c’est un argument GreenIT qui permet de dire au client que nous DEVONS faire comme ça pour ne pas exploser ses ressources et économiser sa bande passante, ses serveurs, etc.

Ce sont des triplettes { op, path, value } avec op = replace / add / remove, mais aussi copy / move / test. http://jsonpatch.com pour plus de détails. On peut bien sûr patcher un envoi à un serveur, mais on peut aussi demander l’envoi d’un patch pour n’avoir que la mise à jour des données, et pas toute la liste. JSONPatch est implémenté dans de nombreux langages, y compris C#. JSONPatch, en fait c’est un DiffGram, mais en JSON au lieu de XML.

Techniques de push : encore plus efficace serait d’envoyer juste l’info en push comme quoi il y a eu changement, puis laisser le client décider de faire l’appel dans l’autre sens pour récupérer la donnée elle-même (avec JSONPatch, au passage).

Exemple utilisé sur les Vélib typique de données nombreuses, mais dont une part faible est modifiée à chaque instant, donc intérêt particulier à ne surtout pas tout télécharger à chaque fois, mais à recevoir uniquement les changements.

Difficile de faire ouvrir un port, et certains load balancers ne supportent pas les websockets. Le système de handshake nécessite un support par le serveur. D’ailleurs, les websockets sont sans garantie de reconnexion lors de la perte de déconnexion.

Conclusion

Comme d’hab’, de la top qualité de présentations au BreizhCamp ! Dommage d’avoir pu être présent que le second jour… Merci à tous les intervenants pour nous offrir de tels concentrés de savoir !

Posted in Retours | Tagged | Leave a comment