Zen M-4 : Zen Metaphor

Sylvain Abélard

Comprendre le dev Web par des métaphores.

  1. 05/06/2016

    Relativité

    Bonjour, aujourd’hui nous parlons de relatif et d’absolu. Le concept est abstrait, mais utilisé partout, mais vous le comprenez déjà très bien. Malheureusement il y a parfois des confusions. Contexte Par exemple, quand vous dites “ma chambre est au premier étage”, on suppose sans autre information qu’il s’agit de votre maison ou votre appartement. Si vous êtes en déplacement, qu’il s’agit de votre hôtel ou lieu de résidence. L’information est relative à quelque chose. Mais si vous donnez l’adresse, il n’y a plus de doute. On peut retrouver votre chambre dans l’absolu. Il y a un contexte qui aide à trouver “à partir de quoi” vous parlez. Désambiguisation Malheureusement la confusion cause souvent des erreurs, non pas de débutant mais d’étourderie, puisque ça arrive aussi aux experts. C’est juste que quand ça leur arrive, ils savent vite le voir car c’est en quelque sorte dans leur “checklist” interne de pistes d’attaques pour débugguer : le débutant ne l’a pas encore et c’est en rencontrant cette erreur (et tant d’autres) qu’il deviendra expert. Le système de fichiers : un arbre Depuis longtemps, les ordinateurs traitent des fichiers, qu’ils rangent dans des dossiers, et on peut mettre autant de dossiers qu’on veut dans un dossier. Bref, on a une sorte d’arbre. C’est une métaphore très utile qui nous sert depuis longtemps, dont “tout le monde” a l’habitude. Elle montre peut-être ses limites, on nous promettait des systèmes de fichiers basés sur des “tags” et peut-être que les terminaux mobiles et les applications Web sont en train de nous changer nos habitudes, mais ce n’est pas encore tout à fait ça. Arborescence de fichiers Bref, quand vous naviguez dans un explorateur de fichier, vous avez un point de départ, un endroit où vous êtes en ce moment, et un point d’arrivée désiré. En version graphique on espère que l’outil vous aide visuellement à situer où vous êtes. Windows, MacOSX et les différents Unix vous proposent souvent plusieurs points de départ : une “racine” d’arbre par support physique : je suis sur un disque dur ou une clé USB quelques points d’entrée : système/applications, mon compte/mes documents Et ensuite on navigue de plus en plus profond dans les dossiers, on remonte, etc. Chaque dossier est noté, pour Unix avec des barres obliques (slash), pour Windows avec des antislash (ou backslash). PATH On pourrait croire que dans la ligne de commande, il n’y a que deux points d’entrée : le dossier racine /, et votre dossier personnel ~. Et bien non ! Il existe une variable d’environnement, le PATH (chemin) qui dira, quand vous cherchez une commande, où aller la chercher. Votre shell va d’abord regarder si c’est pour lui (un builtin), puis dans chacun des dossiers de départ. Faites echo $PATH et vous verrez la liste séparée par des “deux points”, par exemple /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin. Quand vous utilisez des gestionnaires de paquets, ils essaieront probablement d’ajouter dans ce PATH un dossier pour que le système regarde d’abord s’il n’y a pas le binaire voulu dedans. Quand on fait des ateliers d’installation avec des débutants, on se retrouve rapidement à gérer des erreurs du genre : soit l’exécutable n’est pas où on veut, soit le dossier que l’on veut n’est pas dans le PATH. Le Web Quand le Web a été inventé, il était lui aussi calqué sur l’échange de fichiers, la mise à disposition de ressources à des endroits précis, et a très naturellement calqué ses URL (Universal Resource Location), emplacement universel de la ressource, un peu comme des fichiers, d’où les slash dans de nombreuses adresses. Imaginons http://bibliotheque.fr/sciences_et_techniques/informatique/web/url.htm une adresse avec le protocole, le domaine, puis une arborescence de fichiers qui ne devrait jamais changer vous permet aussi de voir un peu la structure qu’ils ont choisi, pour explorer davantage Rails En Ruby on Rails, on fait bien davantage que juste accéder à des fichiers ou des représentations d’enregistrements de base de données. On a potentiellement toute une application qui tourne avec des actions différents et des process métiers spécifiques. Au départ, le routage de base donnait par exemple /users/show/1 pour aller voir les utilisateurs (et le UsersController), son action show (la méthode que vous avez codée) avec l’identifiant 1. REST Dans les applications Rails récentes on ne voit même plus le /show. On ira voir /users/1 et on lui dira quelque chose : on va soit lui demander de se présenter, soit lui ordonner des modifications, soit le supprimer ou juste voir s’il existe sans se soucier des détails… Ce sont respectivement les verbes HTTP GET, POST, DELETE, HEAD. Il y a bien plus de verbes et de nuances dans l’utilisation qu’on en fait, mais ce sont les conventions que Rails utilise, et donc celles dont j’ai le plus l’habitude dans mes projets, ceux que je donnerai aux autres et ceux que je récupèrerai des autres. Encore une histoire de contexte à réexpliquer ou non. URLs En réalité, une requête Web est un peu plus complexe : il y a une partie visible que vous voyez dans la barre d’adresses du navigateur, et une partie cachée qui donnera des informations en plus. Le fameux verbe, les fameuses données à envoyer, les cookies etc. Relatif et absolu Pour en revenir au sujet, on voit bien que répéter l’aborescence est parfois pénible : quand vous demandez votre chemin, on vous donnera souvent à partir de là où vous êtes, allez dans telle direction jusqu’à tel repère etc. On ne vous réexplique pas comment arriver là où vous êtes en ce moment, on ne vous donne pas l’adresse ou la position GPS, mais plutôt quelque chose comme “troisième à gauche”. De même, quand vous donnez une adresse Web, quand le moyen le plus simple est de dire “par rapport à là où vous êtes, allez dans ce sens-là”, ça vous embête de répéter “pour tel site web à tel endroit de départ”. HTML HTML vous permet, dans les liens, via les références hypertexte (href) soit de commencer par le protocole (ou double slash // pour dire “reste comme ça” : HTTP reste HTTP et HTTPS reste HTTPS) et le nom de domaine (zenm4.net), soit à partir du début de l’arborescence du site, avec un slash (/archive ou /img/barque.png) ou encore juste un nom de fichier ou dossier, sans slash, qui signifiera “à partir du dossier dans lequel je me trouve”. Rails Rails cache beaucoup de “magie” dans son helper link_to, ou plus précisément url_for : vous pouvez mettre un objet ActiveRecord, et il tentera de voir si le routage, pris en sens inverse, permet de lui donner une URL vous pouvez mettre des options et il tentera de trouver la bonne URL en imaginant que tout ce que vous lui précisez, c’est parce que ça change, et tout ce que vous ne lui précisez pas ne change pas (changer d’action dans le même contrôleur etc) vous pouvez mettre du texte respectant la norme des liens HTML et il ne devinera rien, considérant que vous savez ce que vous faites CSS Même le CSS s’y met avec la directive position: absolute : HTML permet de décrire une structure de boîtes dans des boîtes, et CSS permet de préciser des règles d’affichage de ces boîtes. Par défaut, tout est dépendant de la boîte dans laquelle vous êtes, donc tout est relative, mais parfois vous voulez préciser que c’est à partir du coin en haut à gauche de la page, donc absolute, voire indépendamment de la page, fixé sur l’écran, donc fixed. Fini la confusion Voilà ! Comme toujours j’espère avoir démystifié le sujet et que cela vous permettra de ne pas vous faire avoir par la suite. Quand votre installation rate, votre fichier n’est pas trouvé, vos liens ne fonctionnent pas en HTML ou Rails, vos affichages visuels sont décalés… vérifier si vous parlez en absolu, ou bien en relatif, et si oui par rapport à quoi. C’est un outil crucial dans votre “boîte à outils de débuggueur”, aussi important et bête que “avez-vous bien branché les câbles”, “est-ce qu’il y a du courant électrique” ou “êtes-vous connecté à Internet”. Clarté et concision Je n’ai pas de préférence entre l’un et l’autre. Chaque cas d’usage fera que l’un est plus pratique que l’autre, soit plus clair, explicite et verbeux, soit plus concis. Si vous pensiez tout savoir, si vous pensez avoir perdu votre temps, rappelez-vous surtout si vous formez de grands débutants que c’est pourtant loin d’être évident : c’est en reformulant les référentiels et en questionnant les bases que de grandes découvertes scientifiques ont été faites (géocentrisme, héliocentrisme, physique de Newton et relativité). Carl Sagan disait “si vous voulez faire une tarte aux pommes à partir de zéro, vous devez commencer par inventer l’univers”. Blague à part, aucune communication humaine ne peut tout réexpliquer, toutes se basent forcément sur des postulats de base. Ça fait parfois du bien de les revisiter pour s’assurer qu’on est toujours dans le même référentiel. À bientôt !

  2. 22/05/2016

    Graphes ? Eek!

    Retour à l’école et aux épisodes “concept” pour parler des graphes ! En première année de prépa en cours d’algo, j’ai vu trois structures de données principales que sont les listes, les arbres et les graphes. Encore une fois, mon but n’est pas que les profs d’algos s’étranglent scandalisés devant ce que je raconte, mais de dédramatiser pour les débutants et leur mettre le pied à l’étrier. Listes, Arbres, Graphes Évidemment il y a énormément à dire sur chacun, la clé est que chaque fois que vous arrivez à représenter le problème que vous avez, sous des formes connues, vous avez tout un ensemble de connaissances à votre disposition. Et à chaque spécificité de votre problème, vous avez soit la chance d’avoir des contraintes qui simplifient les algos connus ou vous permettent d’éviter des prises de tête, soit la malchance de ne pas rentrer dans les cases de ce qui est couramment étudié et présenté, et de devoir trouver les astuces vous-mêmes. On a parlé des listes chaînées, et des énumérations en Ruby, et bien qu’il y ait de nombreuses variantes et astuces à ajouter, je pense en rester là. Je n’ai pas encore parlé des arbres, principalement parce que je n’ai eu ni d’inspiration, ni vu de problème majeur et explicable simplement : soit des étudiants se battre sur des points d’algo assez techniques, soit des gens qui n’avaient pas vu que leur problème était en réalité à représenter sous forme d’arbre, mais le concept en lui-même me semble assez bien compris. Graphes La manière dont je visualise un graphe, c’est un GPS ou une carte des transports, disons le métro parisien. Quand vous dessinez un graphe, vous avez des boîtes ou des points reliés par des lignes ou des flèches. Les relations sont des arcs (“arêtes”), les éléments reliés entre eux, des noeuds (“sommets”). La carte du métro vous représente les lignes et stations, d’ailleurs de manière simplifiée par rapport à la réalité : vous n’avez pas les sorties, les couloirs, le temps de trajet représenté fidèlement. Les deux choses les plus simples à faire avec un tel graphe sont : lister les stations (parcours du graphe sans rien oublier) trouver un plus court chemin entre deux stations Les façons les plus simples de faire sont de choisir un point de départ, et de tout lister ensuite à partir de là. Pour trouver une stratégie adaptée, on doit se poser plusieurs questions. Graphe orienté Est-ce que je peux toujours faire marche arrière ? Dans la plupart des stations du métro parisien, oui. S’il y a un tunnel entre deux stations, il les relie dans un sens et dans l’autre. Mais sur quelques endroits, on a des sens uniques : ligne 7bis ou Michel Ange (Auteuil/Molitor) lignes 9 et 10. Le graphe du métro parisien est orienté (ou dirigé) : si vous trouvez un chemin pour aller d’une station à une autre, le chemin retour ne sera pas forcément exactement le même. Graphe connexe Est-ce que toutes les stations sont reliées entre elles ? A priori, oui. On peut débattre sur le funiculaire de Montmartre, mais c’est à peu près tout. Par contre, imaginez un instant que telle ou telle ligne ou station soit fermée : travaux, grèves, incidents, ou même correspondance fermée vous obligent à changer de trajet. Le métro parisien est si dense qu’on imagine mal une situation où il représenterait deux graphes coupés qui ne peuvent pas communiquer entre eux. À la rigueur, couper le pont de Charenton : le terminus de Créteil est assez loin mais la ligne 8 n’a pas de correspondance après Porte de Charenton. Bien entendu, dans ces cas-là, il n’y aurait probablement pas de métro entre les poignées de stations qui restent seules. Mais si on représente le graphe de toutes les voies ferrées françaises et britanniques, quand le Tunnel sous la Manche est fermé, on a bien deux graphes assez grands qui ne sont pas reliés entre eux. Graphe pondéré Est-ce que tout chemin d’une station à ses voisines prend le même temps ? À Paris, bien sûr que non. Certaines stations sont proches et d’autres éloignées. Si on veut vous proposer un chemin optimal, c’est une information intéressante à prendre en compte : non seulement il y a des trajets plus courts, mais il y a aussi des correspondances plus simples, mais il y a aussi dans la vraie vie le fait de marcher plus ou moins longtemps en surface et choisir les bonnes stations de départ et d’arrivée. En voiture, votre GPS va même probablement avoir des poids différents, voire toute une liste de contraintes : les kilomètres à parcourir, mais aussi les vitesses maximum autorisées voire le trafic en temps réel, pour calculer le temps ; l’argent, les voies limitées en hauteur ou largeur… Plus court chemin À partir de là, vous pouvez envisager plusieurs algos de cartographie par analogies simples : vous partez d’une station, et on va simuler presque tous les chemins possibles entre départ et arrivée. Si vous le faites vous-mêmes, vous allez repasser par plein de stations. Plus rapide, vous le faites avec une équipe, ou disons une infinité de clones de vous-mêmes, qui doivent pouvoir se parler pour comparer les chemins empruntés. Et là, la métaphore a atteint ses limites : quand on rédige un algorithme, on doit se rappeler que l’ordinateur est très bête, il ne se rappellera de rien de particulier sauf si vous lui dites de faire attention. Un algo un peu naïf pourrait l’oublier et ferait des recherches à l’infini, en passant sans cesse par les mêmes stations. Ça nous mène à une propriété et une contrainte de plus : Graphe cyclique Est-ce que partant d’une station, je peux y revenir ? À Paris, oui, vu le nombre de lignes et le fait que presque tous les chemins sont faisables en sens inverse. Comme dans la vraie vie, on sait bien qu’on est en train d’évaluer un chemin qu’on a déjà vu, dans la plupart des algorithmes on va conserver quelque part une liste des sommets qu’on a déjà visités. Cycle absorbant Est-ce que je peux faire tourner le temps à l’envers ? OK ce n’est pas la meilleure formulation, mais imaginons des poids négatifs dans un graphe pondéré. Dans l’image du métro, on ne peut pas revenir dans le temps, aucune arête n’a de poids négatif. A fortiori, il n’existe pas de boucle de transports qui vous ferait revenir dans le temps. Mais imaginons que vous avez construit un graphe pour représenter une suite de choix et d’étapes, certaines où vous payez de l’argent et d’autres où on vous en rend. Si vous trouviez une combine pour gagner de l’argent indéfiniment, pourquoi pas : elle n’est probablement soit pas légale, soit pas éthique, soit avec des conditions de départ particulièrement restrictives, mais pourquoi pas. En tout cas, parcourir un tel graphe pour trouver le coût le moins cher est une question qui n’aura pas de sens, puisque le moins cher serait “moins l’infini”. La plupart des algos de plus court chemin ne savent pas gérer ce cas-là, le mieux qu’ils puissent faire c’est détecter quand ça arrive. Liste d’adjacence On a raisonné tout l’épisode sur la carte du métro. Comment on pourrait stocker de telles informations dans un ordinateur ? Deux des méthodes les plus utilisées sont la liste d’ajacence et la matrice d’adjacence. La liste d’adjacence, c’est quand chaque station connaît ses “voisines”, celles qu’on peut atteindre à partir de là. C’est ce que vous avez affiché ou annoncé dans de nombreux systèmes de transport : la station suivante et les correspondances. On n’en parle pas dans les transports mais bien évidemment, dans votre code, il faudrait mentionner la station précédente si on peut y aller (hors cas du sens unique donc). Matrice d’adjacence Et la matrice d’adjacence, c’est faire un tableau avec tous les sommets en ligne d’en-tête, tous les sommets en colonne d’en-tête, et à chaque case correspondante, ces sommets sont-ils reliés par un arc ? Oui, non, et le cas échéant avec quel poids ? Ça ressemble un peu à ce que vous avez dans les cartes routières ou sur des tickets de péage : à titre indicatif, de telle ville à telle ville, tant de kilomètres ou tant d’euros. Et comme on peut faire l’aller et le retour, c’est souvent représenté sous forme de triangle : je ne peux pas lire “de Toulouse à Bordeaux”, mais je peux trouver “de Bordeaux à Toulouse”. Si le graphe était orienté, on aurait besoin du tableau complet. Essayez de l’écrire sur papier ! À écrire comme à lire, on voit rapidement que la liste d’adjacence est plus pratique quand il y a peu d’arêtes, de connexions, et que la matrice d’adjacence est plus adaptée quand il y a beaucoup de connexions entre les sommets. Ce n’est pas toujours le cas qu’une intuition s’avère vraie, alors autant le noter :) Le cours n’est pas terminé L’épisode va s’arrêter là, mais bien sûr le cours sur les graphes va plus loin : définitions précises, algos différents et calculs de complexité, et puis plusieurs outils de transformation, par exemple représenter un graphe sous forme d’arbre etc. Ça permet quand on coince sur une représentation qui ne nous aide pas beaucoup, de retomber sur des situations qu’on maîtrise mieux, ce qui est une excellente méthode à suivre quand vous bloquez sur un cas précis.

  3. 15/05/2016

    Solution d'urgence

    Suite de l’épisode 15 sur le debugging. On a vu comment un bug peut arriver, et on en a détecté un. Maintenant, comment le résoudre et comment réagir ? Et comment gérer humainement ce qui se passe autour de vous ? Urgence J’avais pris le parti de regarder du côté de la médecine, mais parlons maintenant des interventions et secours d’urgence. Les formations de premiers secours vous donneront trois étapes : protéger, alerter, secourir. Protéger Protéger, c’est éviter le suraccident. Si une erreur source vous cause des problèmes en pagaille, et si vous avez une idée de ce que ça peut être, évaluez rapidement et limitez les dégâts. Alerter Alerter, c’est prévenir qui de droit : qui a été ou est encore impacté, que doit-il absolument savoir tout de suite, pour ne pas le noyer dans les informations inutiles, peut-il agir, que recommandez-vous… Secourir Et enfin, secourir, c’est à dire a minima s’assurer que lorsque les secours arrivent, la personne en détresse n’est pas dans une pire situation qu’auparavant. Si vous résolvez le tout, tant mieux, mais il y aura probablement l’avis d’un professionnel de santé plus tard, question de responsabilités. Reprenons dans notre contexte. Protéger : coupure d’urgence Dans certains cas, et sûrement en accord préalable avec ceux que ça concerne, la solution la plus simple est de “tout couper”. Comme vous pourriez couper le disjoncteur ou le gaz en cas d’incendie, ou l’eau en cas d’inondation de votre appartement : si le site Web institutionnel de votre entreprise est tombé, ce n’est pas sérieux, mais s’il a été “défiguré” par des pirates, c’est pire. Peut-être vaut-il mieux le couper le temps de comprendre et réagir. Souvent, on aura mis des barrières pour éviter les attaques massives : au bout de plusieurs tentatives erronnées pour votre code de carte bleue ou de téléphone, ça se bloque, ou ça attend de plus en plus longtemps. Alerter : qualification de bug Quand vous appelez les secours (pompiers, SAMU…) ils vous posent un certain nombre de questions pour qualifier votre urgence : un nid de frelons ou d’abeilles, ce ne sont plus les pompiers qui gèrent un arrêt cardiaque, c’est plus urgent qu’une jambe cassée un souci de santé exige ambulance et médecin, pas un camion incendie un carambolage avec 3, 10, 30 voitures n’a pas le même nombre de blessés Bref, savoir quels moyens (type, nombre) mettre en face de votre besoin, et s’occuper de vous au mieux sans priver quelqu’un dans une urgence encore plus grave. et selon les cas, faut-il aussi contacter la police ? Les gens du centre de répartition pourront se coordonner avec d’autres services pour alerter, communiquer, limiter les dégâts ou assurer une continuité de service : par exemple lors d’un accident de la route, il y aura les constatations à faire, et la circulation à assurer. Prioriser Une fois identifié, un bug finit souvent dans un outil de ticketing ou bug tracker : un produit du marché, quelque chose de dédié, de fait maison, ou comme très souvent rangé dans un tableur. On apprécie en général de pouvoir noter la gravité de chaque bug, pour savoir ce qui est prioritaire. Et là, la médecine a deux mots utiles pour nous : “aigu” et “chronique”. Une douleur aigue est typiquement courte et intense, elle s’impose à vous. Une condition chronique se fait dans la durée… et peut causer, à terme, des épisodes aigus. À vous de voir comment vous priorisez. Secourir : “cellule de crise” Tous les bugs ne le justifient pas forcément, mais on peut s’inspirer de plusieurs protocoles que mettent en place notamment les pompiers, l’armée, mais aussi des cellules de relation presse en cas d’incident. On trouve assez souvent des process réinventés par chaque équipe, mais les points qui reviennent souvent sont : une seule personne qui supervise et décide une seule personne qui sert de point d’entrée et de communication déranger le moins possible les personnes qui résolvent Bref, une “cellule de crise” ou “war room” pour améliorer la communication et les retours rapides. C’est très bien mais les petits malins se demanderont toujours pourquoi on n’a pas mis en place avant un système de communication inter-équipes efficace. À vous de voir. La vie reprend son cours En parallèle à l’incident ou après celui-ci, il faudra bien reprendre un jour le cours normal des événements. Je ne vais pas m’étendre sur les PCA et PRA, plans de continuité ou reprise d’activité, mais c’est là qu’on verra si vous en avez un, s’il a été testé, et s’il marche. Rétrospective On essaie aussi au maximum de noter les étapes de résolution : si on se rate lors des correctifs, on pourra savoir où et quand on s’est ratés, pour faire une reprise sur incident. Puisque tout est déjà écrit, ça peut aussi devenir à terme un nouveau processus dans l’équipe : si le problème revient, on saura mieux chercher, mieux résoudre, et limiter les pistes à explorer. De même, quand des médecins se renvoient votre cas les uns les autres, ils font parfois pour eux, parfois par contrainte réglementaire, parfois pour la recherche, des notes sur ce qui marche ou marche pas, afin de mieux réagir les fois d’après. Puisque j’ai choisi une analogie avec la médecine, je préfère le mot “rétrospective”, mais on trouve souvent le mot “post-mortem”, notamment dans le cas des attaques informatiques. Blameless Post-Mortems Une bonne rétrospective doit être faite avec des informations fiables pour occasionner le changement voulu : process, doc, code, infra… afin qu’on gagne du temps et de la confiance par la suite. Mais elle se fait forcément après l’incident. On souffre donc : de ne pas la prioriser car on a plus urgent (on ne s’améliorera pas) de la voir se transformer en distribution de claques (culture du blâme) et donc de ne pas avoir d’informations fiables (tendre le bâton pour se faire battre) Là encore, j’espère que si ça n’est pas le cas dans votre équipe, vous aurez l’occasion d’expliquer pour mettre ça en place sereinement. Humainement Pour tout le monde, l’enjeu est d’accepter l’erreur humaine mais d’avoir un process robuste mais flexible, “résilient”, qui résiste à ce genre d’erreurs. Un moyen simple et que le monde hospitalier a mis en place pour cela, c’est une abondance de check-lists : toutes ces questions pour s’assurer que vous êtes bien le bon patient, venu pour telle raison, qui a ou n’a pas pris tel médicament, n’a pas fait tel voyage etc. On parlera peut-être un jour des estimations, qui prendront au moins un épisode à elles toutes seules, mais pour le moment dites-vous juste que, bien que tous mes conseils insistent pour garder son calme, résoudre les choses correctement après enquête, il y a forcément un sens de l’urgence pour certains, et que leur répondre “on verra quand ce sera fait” n’est pas satisfaisant. Empathie et compassion Bien sûr, tout le monde peut le comprendre, que penserait-on d’un médecin qui vous annonce votre problème sans vous avoir examiné ? Question de sérieux, de professionalisme, et de bon sens. Mais quand vous gérez un bug en tant que développeur ou développeuse, pensez à ce que vous répondez à vos clients et demandez-vous “comment je le prendrais si j’étais malade et que les médecins me disaient cela ?” Dans ces situations, n’oubliez jamais de faire preuve d’empathie et de compassion. Non seulement c’est la base du respect, mais vous risqueriez bien d’en apprendre davantage sur le métier, les contraintes non dites, et avoir des idées pour la suite en terme de priorisation, communication, et prévention.

  4. 08/05/2016

    Désinsectisation

    Bienvenue dans l’épisode 15, sur le debugging. On ne va pas parler des méthodes de résolution de bugs, qui vont dépendre de chaque langage, plateforme, et bug bien sûr. Ce qui va m’intéresser ici c’est de voir comment un bug peut arriver, comment le résoudre, et comment gérer ce qui se passe humainement durant les étapes de résolution du bug. Là encore j’ai de quoi faire une petite série, pour l’instant en deux épisodes : aujourd’hui sur la détection et la réaction au bug, et la semaine prochaine sur la résolution du bug. Il n’est pas impossible que d’ici quelque temps on reprenne le sujet si ça vous intéresse et si je trouve encore d’autres choses à dire. Quoi de neuf, docteur ? Pour ne pas épuiser la métaphore sur la voiture, et parce que bien souvent on rabaisse les développeurs à des exécutants techniques, je vais plutôt choisir une métaphore filée sur la médecine. On parle parfois d’un développeur sur un bug comme d’un pompier, un démineur, mais je n’aime pas le côté urgence forcée, et l’absence de responsabilité que cela sous-entend. Pour moi, intervenir sur un bug, c’est comme être le médecin traitant face à quelques symptômes. On pourrait dire chirurgienne, mais j’aime moins l’aspect d’intervention certes d’une haute technicité, mais ponctuelle et qui ignore la santé globale : à résoudre les soucis un par un, on peut facilement oublier d’avoir une vision générale. Les causes Je suis obligé de commencer par la définition du mot “bug” la plus générale qui soit : quelque chose d’inattendu ou de néfaste que l’on attribue (à tort ou à raison) à votre système. Et donc la cause la plus générale qui soit, c’est qu’un postulat sur lequel vous vous basiez… n’est plus valide en ce moment. Ça peut être dans votre infra, vos données, votre code, votre documentation ou vos spécifications. Pour être clair, il y a quelque chose de : physiquement cassé : connexion, serveur… mal tourné dans l’environnement : configuration, dépendances… différent de vos attentes dans les données, ce qui peut “casser” un algo… mal exprimé dans votre documentation, et ça coince ceux qui dépendent de vous pas très clair dans les messages d’erreur ou options proposées pas prévu ou mal anticipé dans vos spécifications dangereux dans la résolution hâtive d’un bug, qui cause un autre bug ! Ou enfin, tout simplement, c’est que votre code est en défaut. Le corps médical a le même problème : outils cassés, prescriptions mal suivies parce que pas claires ou trop contraignantes, situation imprévue, combinaison de médicaments ou de maladies aux effets combinés désastreux… Sans parler de l’environnement global du patient qui serait toxique ou délétères (mauvaises habitudes…) et ça finit toujours pareil : quelqu’un va voir son ou sa médecin (qui est rarement la cause du souci), exige une solution (rapide si possible), et le tout sous peine de conséquences (parfois dramatiques). Le message n’est pas clair De même, un diagnostic est parfois difficile quand il y a une ou plusieurs causes de départ, mais qu’on ne les voit pas parce que les informations sont cachées, conflictuelles, similaires à un autre cas… pensez à la série Dr House si vous voulez un exemple. Mais, c’est pas mon problème ? Pourquoi ai-je tenu à faire cette liste si longue et qui parle si peu de code ? Tout d’abord parce que les cas de la vraie vie sont au moins aussi nombreux. Mais aussi parce qu’on tentera d’attribuer des erreurs de ces huit catégories-là à votre code, faute de mieux comprendre ou par calcul politique. Pour être clair, parce qu’il y a quelqu’un qui pense “ce bug, c’est pas mon problème”. Enfin, pour ne pas vous entendre, en tant que développeurs et développeuses, dire ce genre de phrase. Parce que toutes ces catégories sont ou devraient être de votre ressort : comprendre les implications des choix en amont, en aval, savoir dire non et expliquer les options à ceux qui feront les choix. Accepteriez-vous de voir un médecin qui se dédouane de vos problèmes ? Un ou une médecin a une position de prestige, de pouvoir, et vous êtes en position de dépendance. Les sujets abordés vous touchent directement. Les décisions ont intérêt d’être claires et concises. On n’accepte pas d’être cobaye, de jouer aux devinettes. Toute action doit être motivée et expliquée, y compris quand il s’agit de se dessaisir du sujet pour le confier à un confrère ou une consoeur. Et pourtant, on serait tellement en colère de voir une décision hâtive et fausse prise avec autorité et aplomb, se révéler fausse : on se sentirait trompé, on perd confiance, on peut se mettre en colère ! Mais à l’inverse, ça donne davantage confiance de s’entendre dire “je ne sais pas, on va chercher” ou “j’ai une piste, on va faire des examens pour confirmer”, ou encore “j’ai plusieurs pistes, on va tester pour voir”. Avant le bug : monitoring Je n’ai pas retrouvé de source mais Toyota avait une manière de décrire les problèmes, non par leurs conséquences comme souvent, mais comme étant une déviation de la norme. Les tests médicaux, analyse ou monitorings sont chers ou pas pratiques. On aura tendance à ne les faire que quand tout va mal. C’est un peu dommage, et c’est pourquoi on encourage non seulement à un suivi de ce qui a été mal un jour, mais aussi parfois à un checkup régulier. Avant de se dire ce qui est normal, il faut pouvoir le suivre, savoir ce qui est dans la norme ou pas. Et encore, pensez à la météo, aux pollens ou aux grippes : il y a la norme saisonnière. Pour un site web de commerce, par exemple, quelles sont les heures, les jours de la semaine, les périodes de l’année les plus importantes ? Après le décès de Michael Jackson, Google a reçu tellement de requêtes qu’ils ont cru à une attaque. Après chaque événement marquant, Wikipedia reçoit un flot de modifications plus ou moins légitimes : il est important d’avoir un plan d’action, même s’il dit juste “attention, il se passe davantage de choses que la normale”. Identification du bug L’identification d’un problème est facilitée si vous avez un monitoring en place. Sinon, c’est souvent par hasard, par chance (en anticipation), ou parce que les conséquences de votre bug vont remonter avec bruit. Je pense qu’il y aurait beaucoup à dire, et chaque métier a probablement ses moyens d’améliorer et d’anticiper l’identification de problèmes, mais ça dépend tellement de chaque cas que je vais arrêter là. À la semaine prochaine ! Et voilà, on a vu ce qu’on peut faire avant et au moment où l’on détecte un problème, à la semaine prochaine pour voir comment on peut réagir et corriger ce bug !

  5. 01/05/2016

    Sécurité par obscurité

    Bienvenue dans l’épisode 14 ! On va continuer un peu sur la sécurité, après un épisode complet sur une approche générale et un autre sur les injections. Il nous reste deux types de failles du top 10 de l’OWASP, et dans ma grossière qualification ça donne : “faux et usage de faux” (impostures, arnaques…) “la porte était ouverte” (ou une autre porte) “trop d’infos disponibles” La sécurité par l’obscurité Mais dès qu’on se dit que laisser trop d’infos c’est une mauvaise sécurité, on pourrait croire qu’une bonne sécurité c’est laisser peu d’informations. Bien entendu, ça ne suffit pas. Trop d’infos, ça augmente les chances qu’un attaquant trouve une porte d’entrée, et pourquoi pas un moyen spécifique de l’attaquer (on réduit les possibilités auxquelles il devrait se préparer), mais la base reste quand même d’avoir toutes ses portes bien sécurisées. Si votre clé est sous le paillasson ou sous un pot de fleurs, elle n’est pas en évidence, mais vous avez quand même un double dans la nature et vous ne faites qu’espérer que personne ne le trouvera. Au lieu de vous dire “ma porte et ma clé sont sécurisées”, vous devez alors vous assurer que : personne n’ira par hasard chercher sous le paillasson lors des rares occasions où je dois chercher mon double, personne ne me voit quand je donne la cachette à une connaissance, personne n’entend Et bien sûr puisque vous avez transmis votre confiance, s’assurer que cette personne mérite cette confiance, ne fera pas de double, n’ébruitera pas votre secret, etc. Passe et Backdoor Entre parenthèses, c’est tout à fait l’enjeu du récent procès entre Apple et le FBI : autoriser une “Master Key”, un passe, surtout si c’est public, fait que les attaquants ne vont plus nécessairement chercher à pirater les maisons une par une, mais simplement tenter de récupérer le passe qui leur ouvrira d’un coup toutes les maisons. La porte n’était pas fermée La sécurité d’une chaîne est celle de son maillon le plus faible. L’adage est connu. Le plus bête : vous avez une super porte, mais vous avez oublié de la fermer en partant. C’est le cas “mauvaise configuration” de l’OWASP : vous avez des outils, qui sont bons et bien choisis, mais vous les utilisez de travers, ou vous oubliez de les brancher. La fenêtre était ouverte Presque aussi bête, puisque ça ne vient pas de vous : une de vos dépendances est vulnérable. La porte d’entrée est fermée, mais il y a une fenêtre ouverte au rez-de-chaussée. Tous nos systèmes informatiques et tous nos logiciels sont composés de nombreuses petites parties qui s’articulent entre elles. Si vous vous basez sur tel outil ou telle bibliothèque un peu vieille, sa dernière version a peut-être mis des correctifs de sécurité. Ne pas la mettre à jour, c’est risquer de se faire attaquer par là. Le problème c’est que les dépendances d’un logiciel sont de plus en plus nombreuses et ajoutent elles-mêmes d’autres dépendances. La vérification de chacune devient vite pénible, sauf si vous la faites automatiquement. Heureusement, chaque langage et framework vient de plus en plus avec son gestionnaire de dépendances, et outre les commandes pour installer et mettre à jour des paquets, ces outils proposent souvent aussi de lister les paquets à mettre à jour, obsolètes etc. La porte est restée ouverte trop longtemps C’est un peu le cas du fraudeur qui passe le portillon du métro derrière d’autres : la porte est là, elle marche, elle est plutôt bien dimensionnée, mais il y a des cas où c’est ouvert trop grand, trop longtemps etc. Ce n’est pas suffisant, mais c’est la raison pour laquelle certaines applications vont vous déconnecter après un temps d’inactivité, vous faire changer de mot de passe de temps à autre, vous rappeler de supprimer les accès qui n’ont plus raison d’être, rappeler de ne pas prêter son badge, etc. L’accès pièce par pièce, placard par placard Enfin, la métaphore a là aussi atteint ses limites d’utilité. Je parlais de la sécurité de votre habitation, et il y a un “dehors” et un “dedans”. Une fois “dedans” on peut tout faire. Dans un logiciel, on peut et on veut souvent être bien plus spécifique : une zone pour les administrateurs et une zone pour les clients, très souvent. On pourrait dire aussi : une zone pour la gestion de stock, une autre pour la comptabilité. Un accès pour la succursale de chaque département, et un accès global pour consolider les infos. Imaginez une telle finesse chez vous : le facteur peut entrer s’il a un trop gros colis, mais ne peut que laisser un colis dans l’entrée ; la voisine peut nourrir le chat, mais pas aller dans les chambres ; les enfants ont accès aux placards pour les boissons et le repas, mais pas pour piller les desserts et les bonbons. L’une des failles d’OWASP est d’oublier ou de mal configurer ce genre d’accès. Dans leur section propre à Ruby on Rails, ça donne même un conseil de plus : utiliser les “strong parameters” pour que le concept “modifier un enregistrement” se limite à certains champs, et eux seuls. Je laisse trop d’infos Maintenant qu’il est clair que cacher des choses ne vous sauvera pas, on garde quand même la logique de rendre les attaques plus dures, plus longues, plus complexes et plus visibles. Bref, on peut quand même éviter de simplifier les attaques. Par exemple, un attaquant peut tenter de vous envoyer un email en se faisant passer pour votre banque. S’il se trompe de banque, non seulement il ne vous aura pas, mais en plus il va potentiellement vous mettre la puce à l’oreille pour la prochaine tentative. S’il fait un envoi de plusieurs spams avec chacune des banques les plus probables, l’attaque est plus longue et plus visible, et vous vous doutez non seulement qu’on vous en veut, mais d’où les attaques viennent en ce moment. En cas de doute, vous serez plus enclin à appeler votre banque pour confirmation, et elle vous précisera en général comment identifier un mail qui vient bien de chez eux, et vous précisera probablement que JAMAIS ils ne vous demanderont de mots de passe ou données confidentielles par email. German Tank Problem De même, si vos identifiants sont numériques et croissants, sans même vouloir vous attaquer, vos concurrents sont capables de voir votre progression : tiens, mon compte test d’hier est le numéro 300, mon compte test d’aujourd’hui est le numéro 400, et l’entreprise prétend avoir des milliers d’inscriptions par jour, et des millions d’utilisateurs au total ? Peu crédible. Open API Laisser trop d’infos, comme vos identifiants ou la liste de vos champs, très classique dans le cas d’une API ouverte à l’extérieur, permet à un attaquant de mieux cibler ses tentatives d’injection. Si je sais qui sont les admins, où est le champ qui donne les droits… CSRF Tout cela nous mène au dernier point, la CSRF, prononcée Sea-Surf, pour Cross-Site Request Forgery : fausse requête de site à site. Si un attaquant sait que votre site a une URL qui fait quelque chose, par exemple vous désinscrire, ou valider un transfert d’argent, ou vous faire voter dans un concours en ligne qui l’intéresse, il peut en profiter pour vous faire cliquer ou vous faire faire une requête du genre, depuis un autre site, par exemple avec un lien “cliquez ici pour voir des photos de chatons”. On se protège rarement de cela pour des requêtes en lecture (GET), mais pour un formulaire qui envoie des informations, Rails va souvent ajouter son CSRF-token, un “jeton unique” avec une clé qui permet de se dire “tiens, l’utilisateur souhaite voter pour le concours, mais pourtant il ne connaît pas la clé que je lui ai donnée, c’est donc qu’il vient probablement d’un endroit que nous n’avions pas prévu”. OWASP TOP 10 Bref, révision rapide du top 10 de l’OWASP : Faussaires, imposteurs et passe-passe 1. injection SQL ?. injection shell 3. XSS (Cross-Site Scripting) 10. redirections non vérifiées Je laisse la porte ouverte 5. Mauvaise configuration 9. Dépendances vulnérables 2. Authentification / gestion des sessions 7. Missing function level access control ?. Oubli des `strong parameters` Je laisse trop d’infos 4. Insecure direct object references 6. Sensitive data exposure Un peu un mix : 8. CSRF - Cross Site Request Forgery vous avez confiance en votre browser mais il est prédictible et je vous ferai cliquer sur un lien Je pense que pour la suite du sujet je vais vous laisser vous documenter auprès de qui de droit, la technique et les sujets pointus ne tiendront pas dans un format audio ni en 5~10mn, et j’espère que vous avez une meilleure idée de la sécurité, ses enjeux, et les endroits où vous pouvez intervenir. À bientôt !

  6. 24/04/2016

    Injections

    Bonjour, bienvenue dans l’épisode 13. Dans l’épisode 011. À l’attaque ! on a fait une introduction sur la sécurité : une vision globale pour éviter de se perdre sur la technique, en comparant avec la sécurité de votre habitation. Pour mieux se protéger, il est important de comprendre comment pense l’attaquant, et comment les points techniques de la sécurité se traduiraient dans le monde réel… Disons plutôt le monde physique, par opposition à virtuel ou numérique, parce que vu la place des technologies dans notre vie, le monde numérique est tout à fait réel. Je vais me baser sur douze erreurs classiques listées par le projet OWASP (Open Web Application Security Project), que je classe grossièrement en “usage de documents falsifiés”, “la porte était restée ouverte”, et “j’ai laissé trop d’informations à l’attaquant”. Encore une fois, je ne veux pas vous empêcher de dormir la nuit, mais après avoir acheté et fait installer une porte d’entrée très solide avec des clés compliquées, c’est sûr qu’on se sent bête d’avoir laissé le garage ouvert ou la clé sur la porte. Faux et usage de faux Une énorme partie de ces erreurs vient tout bêtement par “imposture” : un ordre arrive, vous croyez qu’il faut l’exécuter, mais il s’agit en fait d’un mensonge placé là par un attaquant. Le souci c’est que chaque canal de communication sur chaque partie de vos systèmes peut avoir son attaque appropriée. Depuis des siècles, on a aussi plusieurs personnes ou équipes qui vont faire des faux : fausses lettres, fausses signatures, fausse monnaie… Vous faites confiance à l’autorité, à la signature, à un papier qui ressemble à de l’argent, et vous êtes coincés. Injection Encore plus facile que de fabriquer un faux message royal, imaginons que le contenu du message soit : “faites ce que dira mon messager”. Vous prenez la place du messager, et vous avez gagné. Et encore plus facile que tout cela : si le message du roi a une zone blanche dans laquelle vous pouvez écrire tout ce que vous voulez, le message, la signature, le messager ont beau être connus et certifiés, vous ajoutez “et vous donnerez une forte somme d’argent à untel”, et tout tombe à l’eau. De même, vous faites tourner du code sur toute une infrastructure (machine, OS, BDD…) et vous avez besoin que le code leur envoie des ordres. Si ces ordres viennent du monde extérieur, vous DEVEZ vous en méfier. Le plus connu c’est l’injection SQL. On va écrire une requête très simple, SELECT * FROM users where email = "#{params[:email]}" AND active = true et quel que soit votre langage vous aurez une méthode pour dire “dans la chaîne de texte qui représente ma requête, ajoute ici la chaîne de texte qui vient du champ de recherche, du champ login etc. Si jamais j’entre une recherche avec du code SQL dedans, je peux par exemple faire croire que la chaîne email est finie avec un caractère simple quote ou double quote (qui ressemblent à des ‘apostrophes’ ou “guillemets” respectivement), que la requête est finie avec un point virgule, puis je continue à écrire le code SQL que je veux pour détruire ou récupérer vos données (un mot de passe admin par exemple, ou modifier le montant de ma facture), et enfin je termine en mettant le reste en commentaire pour éviter toute erreur de syntaxe. Ça y est, votre base de données fait confiance à la chaîne de caractères ainsi envoyée, mais elle contient de quoi vous attaquer de l’intérieur. En Ruby on Rails, comme dans la plupart des frameworks Web ou bibliothèques pour accéder à la base de données, on trouvera des mécanismes qui évitent cela en interdisant ou en “échappant” les caractères : tout guillemet contenu dans le paramètre email sera traduit afin que la base de données comprenne que ce n’est pas la fin de la chaîne, mais un guillemet dans la recherche : Personne.active.where(email: params[:email]) Autres injections Dès que vous parlez à quelqu’un qui vous fait confiance, c’est le même problème. Il existe l’injection shell, qui envoie des commandes à votre ligne de commande, et via laquelle on peut attaquer le système d’exploitation du serveur. Il y a aussi les XSS (Cross-Site Scripting) : le but pour l’attaquant est d’écrire du Javascript qui va tourner dans la même page que votre site. Par exemple, si dans mon champ email de tout à l’heure j’écris du JS et que dans une page vous affichez mon JS sans “échapper” les caractères, il a gagné. Gagné ? Eh oui, il peut voir plein de choses, comme vos cookies, et envoyer tout ce qu’il trouve sur un autre site. Par exemple, récupérer la session sur votre banque en ligne et émettre des virements. Enfin, en JS, en affichage ou autres, si j’arrive à vous faire cliquer sur un lien qui vous sort du site en question, je peux faire du phishing (hameçonnage en français) : au lieu d’aller sur le site de la banque, vous allez sur un site qui appartient à l’attaquant, aux mêmes couleurs, qui vous fait croire que vous êtes déconnecté par exemple. Vous rentrez alors votre login et mot de passe… sur le site de l’attaquant. Là ce n’est plus du tout une histoire de sécurité sur VOTRE site, mais de filoutage classique où l’on vous met de la poudre aux yeux pour avoir des informations confidentielles. Toutefois, vous pouvez au moins de votre côté et pour vos utilisateurs, éviter le XSS et pour les redirections intempestives, a minima les éviter, interdire, ou les rendre plus difficiles ou plus évidentes : si je dois me reconnecter à ma banque juste après avoir vu “vous allez sortir de votre espace sécurisé”, je suis plus méfiant. alert(‘pwn3d’) Et c’est pour cela que vous voyez des démos de sécurité, où il y a écrit alert("bad security") et un popup navigateur avec le message “bad security”, bien sûr ça ne fait rien de grave. Ce que la personne vient de vous prouvez, c’est que vous êtes vulnérables à ce XSS et à ces redirections de votre site vers un site vérolé. Autres attaques L’épisode est assez long, je vais garder huit autres failles et vulnérabilités pour la suite. Je ne vais pas les dicter mais vous pourrez les trouver, ainsi que des liens vers le site OWASP et la présentation à ParisRB de Dorian Lupu sur la page de l’article zenm4.net/013/ - à bientôt ! http://slides.com/kundigo/if-you-are-hacked-via-owasp-top-10-you-re-not-allowed-to-call-it-advanced-or-sophisticated#/5

  7. 17/04/2016

    Git, ou l'écriture à N cerveaux

    Bonjour, bienvenue dans l’épisode 12 sur Git. Beaucoup de cours pour apprendre à coder se basent sur Git, et c’est très bien de viser tout de suite une bonne pratique qui ne va jamais cesser d’être utile. En plus, un code bien versionné c’est le droit de faire des erreurs et revenir en arrière, ce qui est parfait pour se rassurer quand on tente des choses nouvelles. Mais cela bloque aussi les débutants : je voulais “juste” apprendre à coder, et voilà qu’on me gave d’outils annexes sans vraiment me dire pourquoi ils sont là, si on peut s’en passer au début, ou si on peut apprendre juste quelques parties et se lancer, ou qu’on doit tout savoir dès le début. Du coup le but ici n’est pas de vous faire une liste des commandes (j’ai essayé avec l’épisode sur les itérateurs, c’est beaucoup trop long et pas forcément adapté en podcast, et en plus il y a déjà pléthore de sites et docs très bien faits) mais encore une fois de donner une vue d’ensemble pour dédramatiser le sujet. La tradition orale J’aimerais rapprocher l’écriture de code (du texte à la base), avec quelque chose que l’humanité fait depuis très longtemps : raconter des histoires. Dans toutes les cultures, mythes, légendes, contes se transmettent par tradition orale : les griots, les druides, les aedes grecs… et un jour tout cela se cristallise dans un ouvrage : l’épopée de Gilgamesh ou l’Iliade et l’Odyssée, etc. Comme dans le logiciel ou le business, l’écriture dans une version “canonique” n’empêche pas les reprises, redécouvertes ou réinventions : Molière a repris énormément d’idées de ses fables chez Esope, pourtant il a écrit quelque chose d’original en l’adaptant à sa langue et à son époque. Pourquoi versionner ? On souhaite avoir plusieurs versions d’un logiciel qu’on écrit : soit parce qu’on travaille à plusieurs, soit pour faire une expérience par ci, une tentative par là, sans que cela ne bloque tout le monde. Vous avez tenté quelque chose de trop courageux toute la journée de mardi ? Rien ne marche le soir ? Pas de souci : on revient à la version de lundi. Quand on commence un long chantier sur son code, on ne veut pas le mettre en prod tant qu’il n’est pas fini, pourtant il faut bien que le logiciel avance : une urgence, un patch de sécurité, et on doit soit reprendre la version d’avant votre chantier, soit mettre en prod quelque chose qui n’est pas maîtrisé. Une façon simple de faire ça était de tout copier-coller dans des dossiers, avec des noms plus ou moins explicites (v1, v2, backup, test…) mais plus on va mener de chantiers en parallèle plus ça va être difficile, déjà de tracer, mais ensuite de remettre ensemble à la fin quand le résultat est satisfaisant et “mérite” de rentrer dans le produit final. Les conflits Bien entendu, ça arrive tout le temps. Parfois, pour avancer, on doit se baser sur une hypothèse différente : pour le métier, une découverte qui n’était pas dans le plan de base, une contrainte légale ou une opportunité business ; pour les développeurs, des contraintes ou opportunités techniques. Votre code et votre base de données peuvent avoir des changements majeurs qui mettent une partie du système KO. Quand ça arrive, votre code est en conflit avec celui du voisin. Par exemple, dans l’histoire du barde voisin, le personnage principal meurt, c’est bien plus dramatique, mais vous en aviez besoin dans la scène finale que vous aviez enjolivée : l’un des deux aspects va devoir changer, quitte à faire deux ouvrages. Quand ça n’arrive pas ou très rarement… soit votre projet ne change plus (pas toujours bon signe) soit vous aviez une excellente conception ou architecture logicielle (souvent le genre de choses dont on se rend compte avec beaucoup d’expérience, ou a posteriori). Gestion de version, distribuée Typiquement les versions des contes de Grimm finissent mal et les Disney finissent bien : je ne dis pas que l’un ou l’autre a raison, ils ont chacun leur public, leur époque, leur succès, et sont tous les deux dépositaires d’une version qui est stable et se suffit à elle-même. Chez les développeurs, ce serait un fork du logiciel, et chacun vivra sa vie complètement séparée de l’autre. On ne remet plus trop de Grimm dans les Disney, l’inverse à la rigueur ? Ça peut être un changement de version majeure de la 1.0 à la 2.0, ou deux branches de la même histoire qui coexistent. Mais des scénaristes qui travaillent en parallèle ? Tout simplement sont deux dépôts du même code, qui ont vocation à fusionner un jour en reprenant le meilleur de chaque. Régulièrement, ils s’envoient ou ils vont chercher les modifications de l’autre. Git est prévu pour ça, pour s’échanger les différences pour que chacun puisse profiter des améliorations de l’autre, à condition d’être prêt à résoudre les conflits. Dépôt, branche, versions, table de travail Du coup, Git propose énormément de commandes en fonction des subtilités choisies : cloner, envoyer, récupérer les dépôts ; expérimenter et naviguer entre plusieurs branches des possibles ; voir l’état de votre table de travail, jeter les brouillons ou intégrer les nouveaux travaux à telle ou telle branche ; fusionner les modifications. Enfin, parfois, vous voulez présenter non seulement votre travail à quelqu’un, mais qu’il ne voie pas les annotations et modifications successives : on peut alors réécrire l’histoire des commits. Là encore, ça n’est pas une opération quotidienne ou anodine : maîtrisez d’abord la base et vous saurez par la suite si vous voulez vraiment le faire, et armé de la pratique git que vous aurez eu entretemps, la méthode vous semblera plus claire. Le distribué centralisé C’est compliqué d’imaginer que chacun a sa version. De toutes façon, un seul logiciel finira en production dans votre entreprise. Souvent, on va se dire qu’un des dépôts a autorité sur les autres, disons celui de l’entreprise ou du projet et pas celui des contributeurs. Au lieu de vous synchroniser avec chacun de vos collègues, vous le ferez via celui-ci. Git est si populaire que de nombreux outils de développement se basent dessus : l’intégration continue par exemple, permet de dire “quand une nouvelle version est envoyée à tel endroit, lance des tests, et s’ils réussissent, déploie le tout en production”. Confort maximum, gain de temps : bel exemple d’automatisation. Il existe aussi de nombreuses plateformes, publiques ou privées. GitHub étant devenu de fait un hébergeur majeur de projets Open Source, il y a de fortes chances que toutes les briques dont votre projet a besoin pour fonctionner soient sur GitHub. Si vous avez un outil de gestion de dépendances (npm pour Node, gem pour Ruby par exemple), il y a de fortes chances pour qu’il aille tout chercher sur GitHub. Du coup, bien que Git soit conçu pour être un système distribué, vous venez de baser un système qui se centralise sur GitHub, et en cas de problème chez eux, votre projet est affecté aussi.

  8. 10/04/2016

    À l'attaque !

    Récemment à ParisRB, nous avons eu des présentations sur la sécurité. Dorian et Jean-Baptiste se sont gentiment proposer de continuer avec une série régulière. Tout d’abord je rappelle aux curieux que nous réussissons depuis janvier à transmettre les meetups en live sur la chaîne YouTube ParisRB et que nous avons un Slack qui vous permet de réagir durant l’événement et poser des questions. La sécurité c’est bien joli mais il est difficile de comprendre pourquoi un code javascript alert('pwn3d!') est une faille. Plus que jamais je ne suis pas un expert mais je vise à vulgariser et démystifier ces sujets : je ne suis pas un dentiste, mais je peux quand même vous expliquer comment vous brosser les dents. Acceptez les difficultés Car au niveau de la plupart des développeurs, c’est bien de ça qu’il s’agit : une forme d’hygiène. Avec les bonnes habitudes, et dans une équipe un peu complète, on évite un maximum de problèmes. Dans les cas rares où vous avez des besoins très précis, vous serez au courant avant et vous prendrez vos dispositions. Le monde de la sécurité peut rebuter pour plusieurs aspects. Tout d’abord ça fait peur, et plus que tout autre domaine on a peur de ne jamais être à la hauteur : le sujet est vaste, plein de jargon et de technicité, et comme dans le jeu des gendarmes et des voleurs c’est un jeu d’attaques et contre-attaques, et on a toujours l’impression d’avoir une étape de retard. Ça fait aussi de vous quelqu’un d’extrêmement parano, jusque dans la vraie vie. Et pire, comme “la sécurité d’une chaîne est celle de son maillon le plus faible”, et personne ne veut être le maillon faible. L’approche par le risque Là encore j’ai a priori de quoi faire un épisode complet sur chaque type de faille, mais on va commencer par des généralités. Parlons de la sécurité de votre habitation, et désolé si ça vous empêche de dormir ce soir :) Le premier postulat c’est que tout change et rien n’est certain : “le risque zéro n’existe pas”. On va protéger sa maison contre les cambrioleurs, mais pas contre une attaque au camion bélier ou au lance-roquettes. Les banques et data-centers, eux, peuvent et devraient s’en inquiéter. L’idée est dissuader l’attaquant avant même qu’il tente de rentrer chez vous : trop long, trop compliqué, pour des gains incertains. Analyse de comportements Des études disent qu’une bonne porte et de bonnes fenêtres font fuir la majorité des cambrioleurs : plus le temps passe et plus ils font de bruit, plus ils ont de chances que vous reveniez, ou qu’un passant les remarque. Avec cette approche, une des clés de votre système, ce n’est pas d’être totalement imperméable, mais que toute attaque soit aussi difficile, et longue, et bruyante que possible. C’est comme avoir des caméras de surveillance : ça n’empêche pas le crime d’avoir lieu, mais ça augmente les chances de détection et de retrouver des traces pour punir le coupable. Aucune protection, mais de la dissuasion. Dans vos systèmes, en tant que développeur, vous êtes de toutes façons déjà parti pour tout tracer et analyser : pour votre reporting, votre chef, votre curiosité, votre business, avoir des idées de ce qui est important et ce qui l’est moins… Il suffit de rajouter l’aspect sécurité à cette question : qu’est-ce qui consitue un comportement normal, et qu’est-ce qui sort de la norme ? Mettez en place un système d’analyse et d’alerte, vous ne serez jamais déçus d’être prévenu d’une situation anormale : appli cassée, serveur KO, réseau coupé… et intrusion en cours. Et tant pis pour le voisin ! On dit parfois que si vous êtes dans un groupe poursuivi par un lion affamé, il n’y a pas besoin de courir plus vite que le lion, mais plus vite que la personne la plus lente du groupe. C’est pareil : si votre porte ou votre site ne sont pas ultra sécurisés, on souhaite au moins qu’ils soient plus difficiles à pirater que celui du voisin. On suppose les attaquants ne sont pas totalement idiots et se reporteront sur la cible la plus facile. Le coût total Tout cela coûte de l’argent à mettre en place et à regarder en permanence. Il y a de nouveau un équilibre à trouver entre la prévention, la réaction (qu’est-ce que ça vous coûte de couper puis de réparer), et ce qu’une attaque vous aura coûté entretemps en business perdu. Dans la vraie vie on peut tout à fait mettre des assurances, vous en avez une sur votre logement, et sur votre business, que vous négociez en fonction de votre budget, des risques et des coûts. Bon, ça remplit déjà un épisode, on verra plus tard pour l’explication des méthodes elles-mêmes comme les injections. J’imagine que vous avez de quoi réfléchir, et que vous ne serez pas surpris d’apprendre que la plupart des fans de sécurité que je connais sont aussi très intéressés par la sécurité physique des locaux, et notamment les serrures. Dormez bien !

Tout afficher (19)

Notes et avis

5
sur 5
2 notes

À propos

Comprendre le dev Web par des métaphores.

Informations

  • Création
    Sylvain Abélard
  • Années d’activité
    2016
  • Épisodes
    19
  • Classification
    Tous publics
  • Copyright
    © Sylvain Abélard
  • Site web de l’émission
    Zen M-4 : Zen Metaphor