Zen M-4 : Zen Metaphor

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 erreu

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 b

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’auparava

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

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 f

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

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 rappr

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

Épisode 10 sur des traitements classiques sur les listes. En Ruby on appelle ça Enumerable, mais heureusement les mots sont partagés dans la plupart des bibliothèques et langages. Traitons d’abord quelques oublis classiques de débutants (et d’étourderies d’experts aussi, ne vous sentez pas ridicules quand ça vous arrive, c’est le jeu) sur des listes et “boucles”. each et les itérations Imaginez-vous dans un emploi qui traite des dossiers un par un. Votre méthode de travail est de prendre des fiches, et les traiter. Partons sur un tableau nommé a et contenant les chiffres de 1 à 5. a = [1,2,3,4,5] # ou (1..5).to_a Traiter, ça peut vouloir dire prendre une feuille, noter quelque chose ailleurs, et les remettre exactement à leur place. C’est ce que fait each : le code b = a.each{|x| x * 2} met effectivement un tableau dans b, mais [1,2,3,4,5] et non pas [2,4,6,8,10]. map et les pièges sémantiques Traiter, ça peut vouloir dire prendre un dossier a, ouvrir un nouveau dossier vierge, et mettre dans ce nouveau

Bonjour, bienvenue dans cet épisode 9 sur l’indexation dans les bases de données. C’était l’étape logique juste après l’épisode 8 sur la manière de ranger et rechercher des données. On parlait dans l’épisode précédent de ranger des livres, et d’aller les chercher. Les seuls outils pour cela étaient un ensemble d’étagères et quelques règles non écrites. J’aime bien chercher les règles non écrites : c’est ce qui permet de tout clarifier, et parfois de tout remettre en cause pour créer de nouvelles opportunités. 1) On voulait donner un ordre, mais lequel ? On supposait que la personne qui range ses livres ne se pose pas la question, ou plutôt qu’elle a une réponse toute faite : probablement de haut en bas du meuble, de gauche à droite par étagère. Si c’est vous qui savez, qui rangez et qui cherchez, ça marche, mais bien sûr il faut prévenir les autres personnes qui pourraient vouloir le faire aussi, sinon ils ne trouvent pas le livre (dommage) voire pire : ils “cassent” votre rangement avec des livres en déso

Bonjour, bienvenue dans cet épisode 8 sur les algorithmes de recherche et de tri de données, inséparable de cet autre sujet : les structures de données. Pour moi, une grande partie du travail de codeur (mais pas que de codeurs), surtout débutant (mais pas que), c’est de rentrer des informations, puis chercher des informations. Il y a beaucoup à dire, j’ai écrit de quoi faire deux épisodes, il y en aura sûrement un troisième dans les mêmes lignes plus tard. Ranger et chercher Les deux sont très liés : jeter tous vos livres n’importe où est une méthode de rangement incroyablement rapide, mais la recherche est incroyablement inefficace. Ranger tous vos livres par titre demande du travail, mais revenir chercher un livre par la suite est très rapide, si on se rappelle du titre bien sûr. Autre avantage : si vous n’avez pas le livre, vous voyez qu’il manque là où l’ordre alphabétique l’aurait placé : inutile de le chercher ailleurs, vous savez que vous ne le possédez pas ou l’avez prêté en ce moment. L’altern

Bonjour, voici l’épisode 7, sur les associations dans Rails. Il fait suite à l’épisode 6, où je vous recommande de toujours considérer la cardinalité de ce dont vous parlez : 0, 1 ou N. En pratique c’est aussi ce que vous trouverez dans un diagramme UML ou dans vos bases de données : associations 1 à 0 ou 1, 1 à 1, 1 à N et N à N. Plus qu’un épisode de métaphore, c’est un épisode qui sert de “pont” entre trois domaines : UML, SQL relationnel, et ActiveRecord qui est l’ORM de Ruby on Rails. Là encore, il y a une introduction à Rails et ActiveRecord dans l’épisode 3 sur les requêtes N+1, que je vous recommande si vous êtes perdus. Le cas de l’association L’ORM, c’est la correspondance entre des objets Ruby et des données dans une base de données. On fait une correspondance entre une table et une classe, un champ dans une table et une propriété de l’objet, et un enregistrements de la table avec une instance d’objet. L’enjeu de la modélisation objet est de représenter un modèle pratique et utilisable de la

Bonjour, bienvenue pour l’épisode 6, l’épisode philosophie. Pas de métaphore principale à filer tout le long de l’épisode, parce qu’à chaque fois que je trouvais une formulation, elle semblait aussitôt évidente ou idiote. Mais commençons. Pour moi, il y a trois “quantités” en informatique, que vous trouverez à la fois dans votre code, vos bases de données, et même votre design et vos aspects métier : 0. rien du tout 1. une chose N. une liste d’éléments Quand on parle d’une chose, on doit souvent envisager qu’elle soit présente ou absente. Quand on parle d’une liste, elle peut bien sûr être vide ou contenir un seul élément, plusieurs éléments, voire… une infinité. Questions pièges et découverte du métier À titre personnel et professionnel, ces nuances m’ont beaucoup aidé à communiquer, et parfois soulever des problèmes ou proposer des solutions. Ce sont des recettes et astuces que j’essaie de ne jamais oublier. Quand on vous parle d’une seule chose, demandez s’il y en a aucune ou plusieurs. Ima

Bonjour, bienvenue pour l’épisode 5 et premier épisode business ! Parler business est un peu plus loin de la ligne éditoriale technique de ce podcast, mais 100% dans la ligne des questions que j’ai et auxquelles je réponds très souvent. De plus dans mes communautés Ruby, Rails et Web c’est un sujet clé car tout le monde semble vouloir devenir entrepreneur. Je partais sur une métaphore avec la voiture, mais j’en ai écrit assez pour presque trois épisodes, du coup je vais parler uniquement de l’étape achat aujourd’hui. Alors voici quelques rappels (forcément incomplets mais on pourra étendre la discussion si ça vous intéresse) sur l’achat de logiciels B2B, c’est à dire par des entreprises, et pas du B2C, par des particuliers. Quel véhicule pour quel besoin ? La plupart des voitures suffiront pour un transport de quelques personnes, bagages et meubles. Pourtant on peut acheter des voitures individuelles ou familiales ; on n’a pas les mêmes besoins pour faire des courses ou un déménagement. Là encore, beau

Bonjour, bienvenue pour l’épisode 4 ! Beaucoup de gens y compris des devs expérimentés ont des soucis de CSS. Il y a l’attitude défaitiste qui dit que vous n’y arriverez jamais, il y a l’attitude “pas mon problème” qui refile le bébé à quelqu’un d’autre, et il y a l’attitude snob qui méprise carrément le problème. … et bien sûr il y a l’attitude qui consiste à tester, à apprendre, et à livrer de la valeur à ses utilisateurs et ses clients :) OK, c’est dur C’est vrai que ce n’est pas simple. De manière générale, HTML et CSS c’est dur. Il y a eu des tas de normes qui s’empilent les unes sur les autres, mais le vrai souci était la variété des navigateurs qui ne gèraient pas tout pareil. Ça va un peu mieux et ça va me permettre de ne pas vous parler des astuces IE6, difficiles à contourner mais qu’on connaissait bien, ou IE7, un peu mieux a priori mais que finalement on connaissait moins. Pourquoi c’est dur ? L’intention est louable : on veut séparer la forme et le fond. Vous avez un contenu HTML, que j’a

Bonjour, bienvenue pour l’épisode 3, plus proche de mon quotidien de Rubyiste, sur un oubli classique dans Rails les requêtes N+1, un des premiers symptômes à vérifier quand votre application est trop lente. Je n’aime lâcher personne dans un domaine complètement inconnu, on va commencer par une introduction superficielle à Rails et ActiveRecord, merci comme toujours de me pardonner quelques inexactitudes qui ne sont là que pour éviter la confusion. Ruby on Rails / MVC Le framework Ruby on Rails a été conçu pour faire des applications Web avec une architecture MVC, Modèle-Vue-Contrôleur. On ne rentrera pas ici dans les détails mais vous pourrez trouver de nombreuses ressources sur Internet et dans les liens de cet épisode : jeveuxapprendreruby.fr et mon “Web Primer”, une vue d’ensemble et liste de vocabulaire sur un grand nombre de concepts utilisés dans l’architecture Web et la conception MVC. ActiveRecord et ORM Là encore, le but n’est pas de tout détailler. ActiveRecord est à la fois le nom d’un concep

Bonjour, bienvenue pour l’épisode 2, sur le cache. Commençons par un adage connu de Phil Karlton : “Il n’y a que deux choses compliquées en informatique : invalider le cache et nommer les choses.” Bien utiliser le cache est complexe, mais le concept est simple. Un carnet d’adresses Dans le dernier (et premier) épisode sur les listes chaînées, pour retrouver mon ami Dave, je devais appeler Alice puis Bob puis Carol. Beaucoup de gens dérangés pour pas grand-chose. On peut apporter une solution très simple : garder un carnet d’adresses. Je note le numéro de Dave, et peut-être même celui de Bob et Carol. À chaque fois que je voudrai appeler Dave, je l’aurai directement en ligne sans déranger personne : je viens d’inventer le cache ! Le cache est mort, vive le cache ! Le problème bien sûr, c’est quand Dave change de numéro : plus moyen de le joindre ! On peut voir trois problèmes immédiats : le premier, c’est quand le numéro n’est pas attribué. Pas de Dave, fin de l’histoire. Si je n’ai pas d’autre m

Bonjour, bienvenue pour ce premier épisode de zenm4 : Les listes chaînées Pour cet épisode pilote, parlons d’un point douloureux du langage C. Le C a un avantage pédagogique : comme il vous donne à peine assez d’outils pour travailler, vous êtes obligés de tout faire vous-mêmes et d’apprendre comment marche ce qu’il y a “en dessous” (système, C, UNIX). Lors de l’apprentissage du C, un des premiers blocages que je vois souvent et qui impressionne les gens est celui de la liste chaînée. Cela fait appel à des concepts simples mais qui à ce moment-là de l’apprentissage sont souvent confus : les mélanger, c’est la catastrophe. Une variable Une variable est une boîte, ou une étiquette. On y range des choses qu’on récupère plus tard en “rappelant” le nom qu’on avait utilisé. Quand on y range autre chose, on “oublie”, perd, écrase ce qu’il y avait. Dans certains langages, ces boîtes sont typées : on ne peut y mettre que des couteaux, ou que des fourchettes. Dans d’autres, pas de contraintes. Attention : Cette

Bienvenue à l’épisode zéro de zenm4 ! Qu’est-ce que c’est, d’où ça vient, où ça va ? C’est un podcast court français avec une métaphore par semaine. Avec des thèmes variés autour du code, du développement web et informatique. Ça ira des listes chaînées aux tris, des jointures SQL au concept de cache, de la sécurite au déploiement. Ces thèmes sont-ils complexes ? Souvent oui, mais pas forcément. En tout cas, avec suffisamment de billes pour comprendre les enjeux, les solutions possibles et leurs compromis, on peut raisonner efficacement sur des sujets complexes, et c’est ce que je veux faire. D’où ça vient ? Du langage Ruby, du meetup ParisRB, de l’initiative RailsGirls hebdomadaire à Paris, de la lecture de The Codeless Code. Où ça va ? C’est une expérience, qui se veut SMART : simple, réalisable, limitée dans le temps. Je veux la lancer avec un effort minimal qui me donnera des compétences et des leçons pour la suite. Avantages attendus Si ça aide des gens, j’estime que j’aurai réussi. Avantages possib