Les dernières news, intégration XHTML/CSS, HTML5, développement web, Terragen 2…

News au format RSS
Suivez-moi sur Twitter (Nico3333fr)

Ces modifications simples (custom scroll via CSS) (le 02/07/2020)

Dans la suite directe du billet expliquant qu’estimer est difficile/impossible, voici un récent exemple de modification que j’estimais simple, mais qui ne l’a pas été.

Pour certains conteneurs sur ProtonMail V4, on a la possibilité d’activer un scroll légèrement customisé via CSS. Le tout est fait à coups de scrollbar-width, scrollbar-color pour les navigateurs le supportant, et à coups de ::-webkit-scrollbar et ses amis pour les autres. Cela remplace avantageusement des solutions via JavaScript utilisées sur la précédente version qui posaient autant de problèmes qu’elles en résolvaient (incompatibles avec le zoom ou de faibles hauteurs notamment).

La demande est simple : il faut l’activer par défaut partout. De totale bonne foi, je fais un rapide calcul :

  1. créer une variable pour l’activer ou non ;
  2. la mettre dans le fragment Sass.

Ok, pas de souci, c’est vraiment facile à faire, je prévois de faire ça en une petite heure.

Que pourrait-il mal se passer ?

Effectivement, je fais ces modifications très rapidement… et je teste vite fait. Pas de souci, ça s’active bien par exemple sur la page d’accueil du Design System de ProtonMail.
Je fais un tour rapide sur les pages. Cela va être vite réglé. Que pourrait-il mal se passer ?

Hé bien, notamment sur cette page : mockup des conversations de ProtonMail v4 (et donc sur la v4 en question).

Activé tel quel, le rendu est vraiment pas heureux. C’est encore plus frappant sur les conversations qui alternent en lues (bleu clair)/non lues (blanc).

Un bug du Custom Scroll

En fait, un espace de couleur uniforme est réservé pour le scroll. Et bien entendu, je n’ai pas des contenus de couleurs uniformes (c’est la fin des couleurs uniformes comme dirait la pub qui le vaut bien). Solution ?

  • Essayer de trifouiller la transparence du scroll ? Pas possible.
  • Essayer de mettre le scroll par-dessus ? Soyons sérieux, pas possible.
  • Mettre une bordure sur chaque élément ! Non. Sinon le conteneur n’aura pas la bordure jusqu’en bas si pas assez de messages.

Bref, j’en arrive à mettre un conteneur avec la bordure à l’intérieur dudit conteneur qui aura donc le scroll, ainsi, le design des conversations ne sera pas pété. On peut argumenter sur le fait que le scroll semble en dehors de son conteneur, mais c’est quand même mieux. Au pire, on peut envisager une seconde bordure à droite du scroll pour l’entourer mais ce ne sera pas nécessaire.

Alors, refaisons notre calcul. Activer cela, modifier les composants, tester… sur trois projets ayant leurs spécificités. Tiens, c’est plus long que prévu. Gag, autre effet de bord découvert de nombreux jours après. Pour peu qu’on ait un contenu en dark mode contenant un contenu clair, le tout peut totalement dérailler avec quelques effets de bords rigolos.

Mais bon, c’était l’affaire d’une petite heure hein ?

Des métriques pour suivre l’activité d’un dev ? (le 11/05/2020)

Il y a quelques mois, j’ai suggéré sur Twitter l’idée de faire un billet pour dénoncer les fausses-bonnes idées en matière de métriques pour suivre l’activité d’un développeur.

Hasard du calendrier, le confinement a pu tenter certains emm… – pardon, je reformule – certaines personnes stressées par le contrôle peuvent vouloir suivre l’activité d’un développeur.

Qu’on soit clair, je comprends le besoin… non pas de contrôle bête, mais de suivi. Le suivi est utile. Pour pouvoir planifier, intercaler, gérer d’autres personnes. C’est légitime. Le contrôle bête et méchant l’est sûrement beaucoup moins.

Et dans notre Startuffe Nation, on peut se poser la question d’une métrique magique pouvant quantifier l’activité d’un développeur. En clair, il y a les bonnes et les mauvaises façons de le faire. Commençons par… les mauvaises.

Les mauvaises métriques, parce que c’est NOTRE PROJET

Idée débile numéro 1 : au poids !

Afin de rester poli, j’évacue de suite l’angle « Le dev est là pour pisser des lignes de code ». C’est idiot. Si vous considérez vos dévs ainsi, ne vous fatiguez pas avec de l’humain. Et si d’aventure, vous aviez quelqu’un correspondant à ce profil, gare ! Certes, certaines tâches sont répétitives et/ou reviennent entre divers projets. Mais cela veut peut-être dire que votre organisation paie des gens pour faire du travail de robot. Autrement dit, si c’est le cas, cela peut tuer leur créativité, et donc leur capacité à résoudre vos problèmes. Ou alors, vous avez embauché quelqu’un de pas bon.

Hein, je te regarde, toi, chef de projet/directeur/dev qui clame un « on a toujours fait comme ça, on n’a aucune raison de changer ». C’est bien connu, le Web est réputé pour être quelque chose d’immuable, et tous les projets/contextes sont exactement les mêmes ! (sarcasmes inside)

Revenons au poids, et prenons un petit exemple. Si je regarde la PR qui fait passer ProtonMail de sa v3 à la v4 en cours de conception, nous avons réussi quelque chose d’extraordinaire.

v3 à v4, 50000 ajouts et 3 fois plus de suppressions

Si on paie au poids, nous avons réussi l’exploit de produire une nouvelle version, et les devs paieront pour cela, vu que le code a diminué de manière drastique ! Je passe les chiffres en détail, mais le dégraissage du mammouth a été violent.

Plus sérieusement, on voit bien que cette métrique n’a pas de sens. Une refonte peut être l’occasion de dégager du vieux code moisi ou des parties devenues inutiles.

Idée débile numéro 2 : au commit !

Regardons le contribution graph de react-components, un projet de composants React faits chez ProtonMail (en gros, des trucs partagés dont on se sert sur tous les projets). Quelque chose vous surprend ? (vous pouvez cliquer pour agrandir)

Contribution Graph version 1…

Je suis 3e, moi, le spécialiste CSS de la boite !! Seuls deux devs me dépassent au nombre de commits, et je suis devant 5 autres devs JS. Qu’on me donne une augmentation de suite !!!

Sauf que… il est possible, je dis bien possible, que j’aie été très légèrement malhonnête en présentant cela. Déjà… il ne faut pas croire tout ce qu’on lit sur Internet, et aller à la source.

Contribution Graph, la vraie version, nous sachons

Déjà, on voit le rapport de grandeur est très relatif vu le nombre d’ajouts/suppressions. Et cela n’a aucun sens de comparer des choux et des carottes. En l’occurrence, il est aisé de voir que j’opère moins de modifications, et si on creuse un peu, mon job consiste à ajouter des classes, modifier quelques bricoles sur les composants. En outre :

  • Les 4e, 5e et 6e modifient bien plus de choses que moi et c’est normal, c’est leur job de faire du JavaScript !
  • Cela ne rend également pas compte de l’activité réelle d’autres, qui travaillent plus sur d’autres projets, sont amenés à opérer sur d’autres aspects, etc.

Bref, pour tuer cette idée, j’ajouterai que j’ai même déjà entendu des devs démotivés se sachant surveillés ainsi… multiplier les commits pour chaque virgule ou point-virgule changé. À bon entendeur.

Idée débile numéro 3 : au temps !

Si on regarde bêtement le changement dans la PR : « Punaise, il lui a fallu 4H pour changer deux classes dans les templates de l’app ? Il fait quoi le dev UI, il se fait bronzer les doigts de pied ? »

C’est possible que le dev UI se fasse bronzer oui. Mais ce qui est possible aussi :

  • c’est qu’il ait galéré à trouver le maillon qui foire dans un projet complexe avec des abstractions de malade ;
  • qu’il ait été dérangé entre temps ou demandé sur d’autres trucs ;
  • que le souci ait été particulièrement dur à reproduire ;
  • ou que la sacro-sainte solution soit éclatée sur 4 projets avec 20 contextes, la rendant particulièrement délicate ;
  • ou qu’il soit parti sur une autre piste, et qu’après 20 tentatives, 2 crises de nerfs, 4 arbitrages, un npm i et une crucifixion, le problème ait été réglé différemment (genre le lendemain, un éclair de génie, paf, problème réglé).

Le temps est quelque chose d’impossible à estimer. J’ai plus de 15 ans de métier, et je me gourre encore lourdement sur mes estimations, parce que quantifier l’imprévu ou l’inconnu est tout sauf une science exacte.

Encore ces derniers jours, j’ai estimé deux demandes en mode « oui ça c’est simple, une demi-journée max tout compris », et sans pêcher par orgueil, ça me semblait vraiment simple. Sauf que non : effets de bord, soucis divers imprévisibles. 2 jours de taf.

Et par pitié, ne confondez pas durée et délai. Un jour de taf, si on est sur plusieurs projets, ça peut s’étaler sur plusieurs jours. Allez, je passe sur toutes les autres idées complètement débiles.

De meilleures métriques

Désolé de ce truisme (j’adore placer ce mot), mais faire confiance à vos devs, ça fera partir tout le monde sur de bonnes bases.

Si vos devs disent que c’est compliqué de développer, c’est que ça l’est. Et s’ils disent qu’estimer est difficile/impossible, c’est que ça l’est vraiment. Si on le dit tous, c’est pas un complot des francs-développeurs dans le monde, c’est que c’est vrai.

Voici quelques pistes :

  • De la valeur business est-elle produite dans le temps sur un même produit (je cite une réponse très juste) ?
  • Les clients sont-ils contents ?
  • Est-ce que votre dev est apprécié des autres humainement ?
  • Est-ce que son travail facilite celui des autres ?
  • Maîtrise-t-il sa partie ?
  • Est-ce que les tâches sont expédiées et résolues ?
  • Est-ce qu’au long cours, son travail permet de continuer à garder la vélocité de l’équipe, ou est-ce que cela devient de plus en plus dur ?
  • Est-ce que sa partie facilite des évolutions non prévues initialement ?
  • Etc.

Certes, tout cela est plus difficile à quantifier via une formule magique. Surtout sur des mastodontes que personne ne maitrise.
Ceci dit, avec de la confiance et surtout des ambiances saines, cela se construit.

Après, cela ne veut pas dire que les estimations sont à jeter, mais il faut les considérer comme ce qu’elles sont : des approximations. Cela peut donner une idée – imprécise – de la charge de travail.

Pas plus tard qu’il y a 3 jours, j’ai entendu un Product Owner dire « je me fous de l’exactitude des estimations, tout ce que je veux, c’est avoir une idée de la quantité de boulot, et voir qu’on avance. Et si un jour, la boîte commençait à avoir des lemmings qui n’ont d’autres boulots que de surveiller ça, vous vous barrerez vite car la boite sera devenue merdique ». Tout est dit.

Mais pour conclure : comptez le coût induit par la mise en place d’outils pour gérer la non-confiance, que ce soit en humain, temps, argent, processus, bien-être… et comptez le coût de la confiance. C’est peut-être délirant, mais croyez que la balance est nettement en faveur de cette dernière, sans compter les effets bénéfiques induits.

Note de lecture : Grid Layout, de Raphaël Goetter (le 30/04/2019)

J’ai eu le plaisir de recevoir le dernier livre de Raphaël Goetter, intitulé « Grid Layout, vous allez enfin aimer CSS ». Ce livre est sorti depuis le 18 Février de cette année.

Grid Layout, par Raphaël Goetter

Un livre entier pour un seul module de CSS ! Est-ce bien raisonnable ?

Hé bien, autant dire de suite : oui, et cela ne sera pas de trop ! Si le positionnement en CSS a toujours été une partie de plaisir (tousse très fort) et absolument pas limitatif (s’étouffe en toussant), là, nous tenons un des modules majeurs, car parmi les plus puissants qui soit.

Des choses soit difficilement faisables jusqu’à présent (fusion de cellules) ou souvent bricolées (grilles robustes et responsive, avec des marges négatives par exemple) sont désormais possibles sans bidouillage, et le tout très simplement. Il m’arrive parfois de me servir de Grid Layout, et je me surprends à constater la puissance et la concision de ce nouveau module.

Ce module ne va pas vous dispenser des bonnes pratiques sur CSS (séparation layout/positionnement d’un élément), mais va permettre dans l’absolu de gérer le positionnement global beaucoup plus aisément : on peut commencer à envisager de se passer de conteneurs exclusivement pour le positionnement, Grid Layout permet aussi bien de créer des systèmes complexes que des choses très simples.

En pratique, m’est d’avis que les règles de scalabilité/réutilisabilité risquent de nous faire revenir sur terre dans les intégrations complexes, mais qu’on ne se méprenne pas, le pas franchi avec Grid Layout est gigantesque, les possibilités sont énormes.

Sinon, que dire de plus sur l’auteur, est-il encore besoin de le présenter ? Passionné des CSS et des Knacss, coutumier des bons livres et… coutumier des interventions sur Grid Layout depuis un certain temps. Autant j’avais eu le plaisir il y a quelques années de co-présenter un atelier sur CSS en duo avec lui, mais la dernière fois, j’étais simple élève lors d’un de ses ateliers sur le sujet à Paris Web en 2018.

Je retrouve tout le style de Raphaël - style, CSS, vous suivez - dans ce livre, très proche de son atelier, en bien plus complet bien sûr : expliquer les choses simplement, pas à pas, sans pour autant trainer. C’est efficace, on apprend vite et bien. Le livre se lit rapidement, il se dévore même.

Bref, vous l’aurez compris : je ne peux que vous recommander la lecture de cet ouvrage. Chapeau Raphaël, ton nom truste ma bibliothèque en matière de CSS. ;)

Si vous voulez en savoir plus sur cet ouvrage, voici le site dédié : Grid Layout, vous allez enfin aimer CSS.

Créer un RevealJS light avec CSS Scroll Snap Points (le 07/06/2018)

Cela faisait un certain moment que je voulais tester ce module CSS ainsi d’autres choses, l’occasion m’en a été donnée avec mes slides de Sud Web 2018. Voici un petit retour d’expérience.

Attention, je le dis de suite : certaines parties de ce délire ne sont clairement PAS utilisables en production à grande échelle. Je me le suis permis car j’étais dans un contexte totalement maitrisé… et vous allez voir que je ne m’en suis vraiment pas privé. Grosso modo, c’est un RevealJS en version très light, codé à la rache en moins de deux heures.

Présentation à Sud Web

CSS Scroll Snap Points

L’idée de CSS Scroll Snap Points est de permettre de définir une force d’adhérence aux points d’accroche en cas de défilement d’un conteneur. Le viewport du conteneur doit s’arrêter à un point d’accroche s’il n’est pas en train de défiler. Ce n’est pas clair ? Rassurez-vous, c’est normal !

Un exemple vaut mille mots, allez voir (idéalement avec Firefox) un exemple.

Comme vous pouvez le voir, l’idée des slides en HTML est assez simple. En clair, chaque élément aura une taille de 100% et une hauteur de 100vh. Et dès qu’on se déplacera, CSS Scroll Snap Points permettra d’aller de slide en slide, nativement si j’ose dire.

La petite surprise, c’est que le touch est très très bien géré ainsi (essayez sur une Surface sur Firefox ou sur Edge). Et une fois que le focus est sur la page… les flèches gauche et droite permettent aussi de gérer le déplacement. Vous voyez l’intérêt pour un carrousel par exemple ? :)

En clair, ce module CSS a beaucoup d’avantages. Actuellement, le touch est très bien géré par Edge et Firefox (les points d’adhérence sont effectifs). Chrome et autres ne semblent pas (encore) les gérer.

Dans mon cas, cela s’est limité à définir un conteneur scroll-snap-type: mandatory et scroll-snap-points-x: repeat(100%). Et à donner à chaque slide la largeur/hauteur complète du viewport. Oui, c’est aussi simple que cela.

La doc : CSS Scroll Snap Points

Intersection Observer

Grosso modo, l’idée de cette API est de gérer quand un élément « observé » rentre ou sort du viewport, d’appeler une fonction quand c’est le cas, cela évite de devoir le faire soi-même avec des fonctions plus ou hasardeuses et/ou coûteuses en performance.

Pour être très franc, au début, j’ai voulu utiliser cela juste pour avoir l’occasion de m’en servir (je n’en ai eu l’utilité que plus tard), voir la documentation d’Intersection Observer.

L’idée était de pouvoir ajouter une classe pour savoir quelle était la slide active. En clair, je surveille toutes les slides.

if ('IntersectionObserver' in window) {
// IntersectionObserver Supported
let config = {
root: null,
rootMargin: '0px',
threshold: 0.5
};
let observer = new IntersectionObserver(onChange, config);
slides.forEach(slide => observer.observe(slide));
} else {
// IntersectionObserver NOT Supported
console.log('Whomp Whomp Whomp');
}

Et quand une passe dans le viewport, je lui ajoute la classe is-active et au passage j’ajoute le fragment correspondant dans l’URL.

function onChange(changes) {
changes.forEach(change => {
if (change.intersectionRatio > 0.5) {
change.target.classList.add('is-active');
history.pushState(null, null, location.pathname + location.search + '#' + change.target.getAttribute('id'));
} else {
change.target.classList.remove('is-active');
}
});
}

C’était un caprice au début, mais cela va se révéler utile ensuite.

Ajouter des contenus qui apparaissent/bougent

Dans la présentation, à plusieurs moments je me suis dit que ce serait bien d’avoir des contenus qui apparaissent au fur et à mesure dans la même slide. Du coup, j’ai mis quelques boutons ainsi.

<button class="js-next" data-next="next_2">Ce qui change…</button>

En clair, quand ce bouton est activé, il va chopper l’élément qui a l’id next_2 et il le fait apparaître.

Oui c’est pas génial point de vue accessibilité, on peut faire mieux, je sais ! :)

Gérer la télécommande

Durant les répétitions, je me suis rendu compte que devoir me rapprocher de ma Surface pour activer les boutons/passer les slides était gênant pour le rythme et ma liberté sur scène (et bien m’en a pris vu la configuration du lieu le jour même). C’est là que je me suis amusé à coder un peu de raffinement… qui va s’avérer vital durant la présentation.

Grosso modo, la télécommande envoie un événement clavier (voir keycode.info), comme si on appuyait sur Page Down (34) ou Page Up (33). J’avais déjà codé que si cet événement arrivait, j’appelais une fonction qui passait à la slide suivante/précédente. Pour l’animation, je ne me suis pas cassé la tête, j’ai utilisé scrollIntoView, et comme je n’avais pas de souci de compatibilité, j’ai utilisé l’option behavior: "smooth" (attention, le support est très variable selon les navigateurs, la version de base ne marche pas trop mal, mais scrollIntoViewOptions est plus rare).

Comme je voulais pouvoir activer les boutons, l’idée est assez simple : si j’ai un bouton non encore activé dans la slide active, alors j’envoie un clic dessus.

if (eventName === 'keydown' && 34 === e.keyCode) {
let activeSlide = document.querySelector('.slide.is-active');
let buttonNext = activeSlide.querySelector('.js-next:not(.has-been-pressed)');
if (buttonNext) {
buttonNext.click();
} else {
let buttonAnim = activeSlide.querySelector('.js-anim:not(.has-been-played)');
if (buttonAnim) {
buttonAnim.click();
} else {
let slides = [].slice.call(document.querySelectorAll('.slide'));
selectSlideInList(slides, 'next');
}
}
}

Dans la fonction qui permet de revenir en arrière (sait-on jamais, des fois que j’en aie besoin durant la présentation), j’ai réinitialisé les boutons d’animation et suivants. Ce n’est pas optimal, mais ça me permettra de les rejouer si besoin est.

Et hop, le job était fait, je contrôlais l’intégralité de la présentation à la télécommande. Bien m’en a pris, car ce sera obligatoire sur place.

En conclusion

Certes c’est un exercice de style fait à la rache, mais grosso modo, avec quelques APIs, de la CSS, très peu de JavaScript et un peu d’huile de coude, j’ai pu tester quelques trucs et recréer un mini-système façon RevealJS en très peu de temps.

Il serait assez facile d’ajouter une version imprimable, de perfectionner le système, j’avais même fait quelques essais pour avoir des slides horizontales et verticales, à creuser pour plus tard, car là je n’ai clairement pas eu le temps.

Là où je me dis que cela est intéressant, c’est pour un hypothétique carrousel : on n'aurait plus à gérer le touch à coups de JavaScript, mais tout serait fait automatiquement grâce à CSS Scroll Snap Points… quand il fonctionnera correctement chez Webkit.

Voilà, si vous avez des remarques ou des commentaires, à votre disposition !

Le manifeste du développeur à moyen ou long terme (le 01/05/2018)

La vision à court terme n’est pas un gros mot, mais fonctionner uniquement ainsi ne m’intéresse pas.

On va se lâcher avec des trucs super récents ? Fort bien, mais si cela n’est pas raisonnablement consultable, le plaisir est de courte durée. Le front-end est un milieu hostile, et dompter cette hostilité est un plaisir.

Être à la manœuvre ? Pourquoi pas. Mais avec l’expérience, je prends autant voire plus de plaisir à créer les systèmes qui permettent aux autres de réussir ou du moins de créer un écosystème qui progresse à son rythme, mais qui progresse toujours. Et un client raisonnablement indépendant est un client qui nous demande des choses à forte valeur ajoutée. Je n’ai rien contre produire des pages, mais ne faire que cela… je peux être mieux employé.

Tout industrialiser ? Pas nécessairement, mais investir du temps pour en gagner, là je dis oui.

Projet innovant ? Pourquoi pas. Et si on innovait en maîtrisant la qualité et l’accessibilité aussi ? Je prends autant mon pied sur un petit projet bien ficelé que sur un truc énorme, tant que mes indicateurs ne descendent pas en-dessous de 90.

Vous croyez que je refuse les challenges ? Disons que les projets licornes qui vont faire trimer un débutant ne sont pas assurance de kif chez moi, cela peut l’être mais pas nécessairement. Je prends autant et surtout mon pied sur des choses que personne ne voit mais que tout le monde apprécie.

Même si j’en suis capable, ne me parlez pas trop de projet dont les 6 mois nécessaires à un bon travail vont être compressés en deux mois, et où il faudra de nouveau 6 mois pour éponger tant bien que mal les tonnes de dette technique accumulées. C’est épuisant. Autant pour le budget que pour mon moral. Ce sont des trous sans fond. Personne n’en est jamais content in fine. Un peu de dette oui, des tonnes non.

Avantage en baby-foot ? Parlez-moi plutôt de formation. Vous voulez que je valorise vos projets, valorisez donc mon savoir et faites-le mûrir. Je ne sais pas tout, mais j’ai soif d’apprendre. Même si je peux et vais avoir la trouille face à l’inconnu, mon envie d’apprendre la surpassera quoi qu’il arrive.

Si vous misez sur moi au long terme, vous aurez du retour sur investissement continuellement, et sur du long terme. Parlez-moi de vision, montrez-moi où vous voulez aller, je vous dirais comment nous y irons.

Ceci est mon manifeste.

Déployer cache-control: immutable avec du cache-busting (le 08/02/2018)

L’autre jour, je m’amusais à tester mon site Van11y sur divers outils, et notamment celui-ci : Sonarwhal.

Ce dernier propose une piste d’amélioration que je n’avais pas essayée jusqu’à présent, à savoir implémenter Cache-Control: immutable. J’avais entendu parler de cette possibilité via ma veille habituelle, mais je n’avais jamais essayé en pratique.

cache-control: immutable

Cache-control: immutable

Cette possibilité a été motivée principalement par de gros sites comme Facebook. Ces derniers ont constaté que bon nombre de leurs utilisateurs utilisaient énormément la touche F5 (allez savoir pourquoi !). Les éléments dits statiques sont bien mis en cache, mais toutefois le navigateur doit deviner quels éléments ont été modifiés, il réinterroge donc le serveur qui lui renvoie un code 304, qui lui signifie « Non modifié ».

En pratique, sur de tous petits fichiers, le coût de cette revalidation est plus élevé que de re-télécharger le fichier en question. Ajoutons à cela qu’un site comme Facebook a beaucoup de fichiers statiques (images, etc.) et d’énormes besoins en temps serveur et en bande-passante. Et comme dirait La Palice :

La requête la plus rapide est celle que l’on ne fait jamais.

Bref, l’intérêt de Cache-Control: immutable ? Grosso modo, c’est d’éviter cette étape de validation, en disant au navigateur que l’élément en question ne changera jamais, il est dit « immutable ».

Ce « petit changement » implique certaines précautions.

Avoir une stratégie de cache-busting

J’en avais une sur les CSS et sur le JavaScript (qui sont faits automatiquement), mais j’étais quelque peu fainéant sur d’autres éléments. Qu’à cela ne tienne, c’était l’occasion de s’amuser à le faire comme il faut, sur un site avec relativement peu de contenus.

Autant le dire de suite : dans ce cas, je l’ai fait de manière très artisanale. La plupart des CMS et bon nombre d’autres systèmes le font pour vous automatiquement.

En pratique, sans cette stratégie, si vous envoyez le fichier /images/logo.svg, et si vous deviez mettre à jour ce fichier sur votre serveur, il faudra le renommer. Vous voyez l’écueil ? Changer à la main le nom d’un fichier sur un nombre conséquent de pages n’est absolument pas gérable.

Il existe toutes sortes de techniques de cache-busting, mais la plus passe-partout consiste à utiliser de l’URL-rewriting (la réécriture d’adresse en bon français). En clair, on va demander au serveur de réécrire l’adresse /images/logo_<ici une valeur qu’on fera changer>.svg en /images/logo.svg. Cela peut se faire via un htaccess :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)_(\d+)\.(css|js)$ $1.$3 [L]

En clair, si l’URL demandée n’est ni un fichier ni un répertoire, et avec les extensions ci-dessus, alors fichier_xxxxxxxx.extension va être réécrit ainsi sur le serveur fichier.extension. Par exemple, css/styles_mini_1516114378.css sera réécrit en css/styles_mini.css (et ce fichier est bien sur mon serveur).

Par contre, c’est bien l’URL css/styles_mini_1516114378.css qui va être mise en cache. Une mise à jour sur la CSS ? Le cache-buster va être mis à jour, par exemple en css/styles_mini_1516114666.css.

En pratique pour le cache-busting

Grosso modo, j’ai repéré tous les types de fichiers qui devaient en bénéficier, et j’ai mis cela dans mon htaccess principal :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)_(\d+)\.(css|js|webmanifest|ico|png|jpg|svg|js|eot|ttf|woff|woff2)$ $1.$3 [L]

Ensuite, il a fallu ajouter le cache-buster partout où il est nécessaire. Sur les img de contenu, j’ai utilisé une fonction en PHP qui renvoie le timestamp Unix de dernière modification du fichier (filemtime()) et qui insère le cache-buster dans le nom du fichier.

return '_'.filemtime($prefix. $chemin_img);

Dans la CSS, pour les rares images et autres éléments utilisés… fainéantise absolue, je l’ai fait à la main. Si si. Il existe des outils qui le font pour vous. Là, les besoins étaient si maigres… que j’ai eu la flemme.

Pour les fichiers CSS, là j’avais déjà des fonctions qui le faisaient automatiquement, en plus de faire d’autres choses (minification, calcul d’intégrité, etc.). Idem pour le JavaScript.

Comme les démos du site sont reprises depuis les dépôts Github de chaque projet (pour m’éviter de me fatiguer quand je les mets à jour), j’ai modifié les fonctions qui récupèrent les fichiers pour ajouter les cache-busters aux bons endroits (CSS et JavaScript). Hop, tout est automatisé, point d’effort.

En pratique pour déployer l’en-tête proprement dite

Une fois la stratégie de cache-busting correctement déployée, il ne reste plus grand chose à faire, j’ai mis ceci dans mon htaccess habituel :

<FilesMatch "\.(css|js|webmanifest|ico|png|jpg|svg|js|eot|ttf|woff|woff2)$">
<IfModule mod_headers.c>
Header set Cache-Control "public, max-age=31536000, immutable"
...
</IfModule>
</FilesMatch>

Et c’est terminé.

Un point de détail amusant : Sonarwhal va – à juste titre – vous gronder si vous déployez Cache-Control: immutable sans stratégie de cache-busting. L’outil ne reconnaissait pas celle que j’avais utilisée, je le signale aux développeurs, qui ont été super réactifs et qui ont mis l’outil à jour. Un bravo à eux !

Un autre point de détail : Cache-Control: immutable ne sera honoré sous Firefox que si le contenu est servi en HTTPS. Cela semble assez logique : il faut être sûr que le contenu n’ait pas été modifié entre le serveur et le navigateur.

En conclusion

Disons-le clairement, l’impact sur les performances sur un site ultra-léger et rapide comme Van11y est quasi-nul. C’est d’autant plus beau que c’est totalement dispensable. :)

C’est un petit exercice de style auquel je me suis livré, plus pour m’amuser qu’autre chose. C’est toujours l’occasion de mettre des bonnes pratiques en place, sur des projets sympathiques et peu chronophages. Ces bonnes pratiques sont utiles même si vous ne déployez pas Cache-Control: immutable.

Pour en savoir plus :

J’ai arrêté de troller, retour d’expérience (le 30/12/2017)

Un peu de pop-corn mais sur un sujet sérieux : depuis quelques années, j’ai fortement limité ma consommation de trolls.

Attention : des traces de glu… de second degré peuvent être présents dans ce billet.

L’existant

Troller, quand on est dans l’informatique (le militantisme aussi), c’est un peu comme une seconde nature (même une première nature chez certains et certaines).

Que celui ou celle qui n’a jamais participé à une discussion sans fin sur un sujet (Emacs/VI, Linux est-il prêt pour le desktop, CSS est-il un langage, les classes atomiques/les classes sémantiques, etc.) lié à l’informatique me jette la première pierre. Il est difficile de trouver un domaine en informatique avec un nombre raisonnable de personnes intéressées qui n’y échappe pas (cela doit être un corolaire de la loi du point GodWin).

Ajoutons que les réseaux sociaux ont tendance à favoriser cela : un message court peut être moins précis, et donc mal interprété, et donc déclencher une réaction, etc. Leur instantanéité n’est pas un mal en soi, mais autant prendre conscience que c’est pas le meilleur endroit pour se sevrer. Et disons-le clairement, certaines personnes ne cherchent que cela : vous faire démarrer (ou se mettre en colère).

Protocole de désintoxication

Un sevrage brutal est trop difficile pour commencer. Il faut soit trouver un substitut (un commit tous les jours est un exemple), soit commencer à se désintoxiquer progressivement.

Si vous rechutez plusieurs fois avec les mêmes personnes, limitez-en la consommation. Trop écorchées vives, ces personnes vont vous faire rechuter systématiquement… et avec l’effet de manque, vous rechuterez encore plus violemment. À la fin, si c’est en arriver à ce que les défenseurs de la cause animale s’engueulent avec les témoins de #balanceTonPorc (si si, je l’ai vu), autant fuir.

En pratique

Perso, j’ai trouvé un réflexe. Avant de réagir à un sujet potentiellement polémique, je me pose les questions suivantes :

  • Cela va mener à quoi ? Si c’est à rien, autant se taire. (refaire Boostrap en Dart… Thomas, si tu me lis, je t’aime)
  • Y a-t-il des chances pour que la discussion parte en live ou que mon propos soit mal interprété ? Si oui, ne rien dire ou éviter (***-nazi(e) si tu me lis).
  • La personne est-elle prête à entendre un avis différent ? Si non, autant la fermer… votre bouche, pas la personne (trop difficile en plus).
  • Est-ce que je commets une généralisation abusive ? Si je peux trouver un contre-exemple, fut-il le seul sur la planète (si si, j’ai trouvé des végans mesurés dans leurs propos), interdiction de dire la chose.

Du coup, cela me permet d’attribuer un nombre de points troll. Après, pour se sevrer, un bon atout : la fainéantise. J’économise mon énergie et je suis lent à réagir… du coup le temps que la vague soit passée, vous arrivez quand les trolls sont épuisés (savoir si les poins médians sont une maltraitance de la cause animale, savoir si la transpiration sur le vélo implique plus de consommation d’eau pour nettoyer le vélo-taffeur, etc.), et curieusement, il est plus facile de s’en détacher quand les arguments sont à la ramasse.

Le nombre de messages que j’ai commencé à écrire… puis tout à coup, je les efface et je me dis « Non allez, ça sert à rien ».

Ce que les trolls disent de nous

En fait, le troll révèle ce qui nous touche (et qui fait mal des fois). Comme disait le regretté Coluche : plus ils se passionnent et plus ils sont cons (je suis le premier passionné par pleins de choses). Je vous laisse mettre la catégorie que vous voulez là-dedans.

Je me permets de m’auto-citer :

Les trolls c’est comme le populisme : tout le monde sait que c’est idiot, que ça ne sert à rien, mais ça rassure nos misérables certitudes et ça réconforte.

(vous n’imaginez pas le travail sur soi pour dire cela, je me suis senti grand l’espace d’un tweet)

Les résultats

Curieusement, cela libère du temps et vous savez quoi ? Cela fait du bien. Je n’ai jamais autant écrit que cette année de désintoxication. Et cette haine que se cultive durant les trolls sévères, vous pouvez la remplacer par de l’amour ou de la tendresse. Et vous savez quoi ? Oui, cela fait du bien. Vraiment.

Dites-vous bien que pendant que vous trollez, d’autres sont en train peut-être de révolutionner le monde en faisant quelque chose.

En fait, si vous avez du mal à décrocher, vous pouvez aussi compter les points. Avec un peu de popcorn (sans lactose), c’est très sympa. Notamment quand les personnes disent la même chose et sont d’accord sur le fond (la spécialité des experts accessibilité).

Après, vous pouvez même prendre de la hauteur sur des sujets. Il m’arrive de voir des sujets resurgir de temps à autres (sur les intitulés de métier, sur la guéguerre graphistes/dévs, alors que tout le monde sait que les graphistes sont des fainéants et les dévs de gros butés comme des coins), et de les lire de manière amusée.

Troller bio et pas industriel

Curieusement, dans mon imaginaire, troller est lié à l’humour. Même si je ne fréquente plus tant certains très bons sites comme LinuxFr, le troll a quelque chose de positif, d’amusant. Le bon troll doit être absolument catégorique sur un sujet subjectif, et suffisamment gros pour que cela se voie (sinon ce n’est pas du troll, c’est de la malveillance).

C’est pour ça que je me dis en fait qu’il faut troller bio, troller VIP… en fait, troller, c’est un peu comme dire des jurons. Quand on le fait tout le temps, on en perd toute la saveur, et ce plaisir délectable qu’ils procurent. Troller devrait être l’exception, alors si je ne dois troller qu’une fois dans l’année, je veux le faire avec des gens biens qui partagent ma vision du troll. Si nous sommes ce que nous trollons, alors je ne veux que troller de bonnes choses.

Et surtout avec des gens qui savent se moquer d’eux-mêmes (pas comme ces intés bouffeurs de patates passionnés d’accessibilité qui font chier la terre entière avec leur amélioration progressive et leur qualité web, ce sont vraiment les pires).

Et au fait, on dit pain au chocolat, pas chocolatine ! Une chocolatine, c’est un petit chocolat (le suffixe -ine est un diminutif, et on va encore dire que le changement de genre lors du passage au diminutif n’est pas une bonne chose). Sans blague.

Un commit tous les jours (le 17/11/2017)

En début de cette année, je me suis essayé sur un coup de tête à me lancer à faire un commit tous les jours. Il faut dire que ma salle de bain m’envoyait un message subliminal depuis des années (si si, c’est bien ma salle de bain).

Ma salle de bain, seuls les vrais sauront

Voici un retour d’expérience.

Un constat

Grosso modo, en 2016, j’avais fait 511 contributions sur Github. Mais le tout était très disparate, je manquais de régularité. En clair, j’ai un souci, je n’ai pas 2 à 3 heures à disposition quand je veux, la vie, toussââââ…

L’idée proprement dite

Du coup, je me dis que je pouvais me lancer là-dedans. L’idée de base : remplir presque à tout prix le contribution graph, et surtout, plus sérieusement, consacrer toujours un peu de temps chaque jour à avancer des choses, que ce soit sur CSP, Röcssti, Van11y, les plugins accessibles avec jQuery ou d’autres choses.

L’idée est clairement de lisser la charge et de l’étaler. Comme je n’ai que difficilement 3 heures à disposition, hé bien, je vais l’étaler à coup de 5/10 minutes.

En pratique

Pour être honnête, quand je me suis lancé là-dedans le jour de l’An, je ne pensais pas tenir 5 jours. Pendant un mois, tous les jours, je n’avais pas de visibilité au-delà de 3 jours, des fois moins.

L’idée est d’avoir au moins un projet qui vous permet de commiter rapidement et sans se prendre la tête. Le jeu – car cela doit rester un jeu – doit toujours être amusant, jusqu’à ce que cela se transforme en habitude. Clairement, pour moi, c’est mon dépôt sur CSP qui est là pour cela.

Il m’est arrivé quelques rares fois de faire des commits de pur confort, genre remplacer un bout de texte, ce genre de chose… mais ce fut très rare. Bon, une connexion en carafe impliquant de faire des commits depuis mon iPad sur Github est une excuse tout à fait valable, si si ! Le dernier week-end, je suis allé squatter la connexion d’un voisin qui n’était pas là... croyez-le ou non, mais là on apprécie quand il fait 5 degrés en extérieur de pouvoir faire un commit en 30 secondes.

Autre astuce : savoir se restreindre. Une mise à jour à faire sur tous mes plugins jQuery ? Hop, on ne fait pas tout tout de suite, une ou deux par jour (n’oublions pas que mon objectif était de lisser la charge).

Attention : contribution ne veut pas dire code. Bien au contraire. Ouvrir une issue, modifier du texte, etc. cela en fait partie, et c’est très bien aussi. Dans l’absolu, il est possible de faire cela sans coder.

Retour d’expérience

Au début, je ne savais pas trop où j’allais avec ça, ni si ça allait durer. C’est de la démarche à long terme, il faut le voir comme un décrassage sportif, une sorte d’entretien, une hygiène.

Le résultat sur mon contribution graph n’est pas définitif, mais il est plutôt intéressant.

Contribution graph de Nico pour 2017 (y a beaucoup de vert)

Un bon point : comme j’ai pris de bons réflexes, j’ai tendance à éviter de reporter la publication d’une mise à jour, ce qui évite les reculades façon « j’y ferai plus tard, c’est-à-dire jamais ».

Ne croyez pas pourtant que cela va vous mettre à jour sur tous vos dépôts… je peine à suivre pour certains plus ou moins prioritaires. Et les journées ne font que 24 heures. D’ailleurs, ne l’oubliez jamais quand vous vous apprêtez à ronchonner sur un projet gratuit, la personne qui le maintient ne vous doit rien dans 99% des cas.

Après, oui certes, il y a quelques trous dans le calendrier. Ce qui est drôle, c’est que je suis presque capable de vous dire pourquoi à chaque fois : un ralentissement durant les vacances d’été (c’est le principe des vacances), un redémarrage post-vacances difficile, un long week-end de pure déconnexion et de bonheur durant quatre jours, etc. Ce calendrier me parle et raconte des bouts d’histoire.

Côté travail accompli, j’en ai ressenti les bénéfices au bout de plusieurs mois. C’est parfait pour accumuler des connaissances, faire avancer petit à petit des choses, au fil de l’eau. J’ai encore au moins 50 commits d’avance sur mon dépôt sur CSP.

Contreparties : j’ai beaucoup moins blogué cette année. Ce n’est pas uniquement dû à cela, mais cela a joué. Ceci dit, je compense le manque d’écriture publique (et encore, j’avoue être très fan d’écrire pour les #mercrediFiction sur Mastodon, et j’ai quand même commis quelques articles et billets) par d’autres échanges, en privé. C’est peut-être l’année où j’ai le plus écrit, et vous savez quoi ? Cela fait du bien.

Il est aussi difficile de démarrer de nouveaux projets ainsi, surtout s’ils demandent beaucoup de temps. Ceci dit, se cantonner à des tâches de maximum 10 minutes pourrait être une approche, à tester. J’ai plusieurs scripts qui me trottent en tête, mais l’accouchement s’avère difficile. C’est pour cela que j’adore prendre le train durant des heures, le dernier script sur Van11y a été codé ainsi, à l’aller pour Aix en Provence (coucou Sud Web).

Conclusion

Si cela vous tente, c’est une expérience intéressante. Pour l’instant, je ne me vois pas l’arrêter, j’ai pris cette habitude. Cela convient bien à ma façon d’avancer, lentement mais sûrement. Je ne suis pas un sprinteur mais un coureur de fond.

Je ne peux pas dire si cette expérience est adaptée pour tout le monde, ce mode de fonctionnement a ses avantages et ses inconvénients. Peut-être est-elle moins adaptée pour de gros développements, je n’oserai pas prétendre que c’est adapté à tous les cas de figure et à toutes les personnalités. Ceci dit, je trouve cette expérience positive.

Paris Web 2017, petit retour (le 17/10/2017)

Paris Web est l’événement locomotive du début de l’automne de chaque année. C’était ma septième édition. Autant ne pas tourner autour du pot, cette édition a été encore une fois exceptionnelle.

Paris Web 2017

Du beau, du bon, du brut mais pas de truand

Curieusement, il est difficile pour moi de dire quelle conférence j’ai préférée… car je ne peux répondre à cette question au singulier. Au bas mot, je retiens :

Et je suis en train de rattraper celles que je n’ai pas vues (il m’est arrivé de discuter et d’oublier que les conférences reprenaient !), et elles sont tout aussi bien. Boris, tu m’as fait claquer de rire avec ton magasin.

Côté accessibilité

Hé bien, je n’ai pas été déçu. Beaucoup de bons sujets, autant sur les bases que sur pleins d’aspects. Julie, Sylvie, Lena, Olivier, etc. vous avez toutes et tous été intéressants.

Restent les petits moments de grâce, où une auditrice pose sa question en LSF, l’interprète traduit, et la personne sur scène répond… et tout cela marche, et c’est juste bien.

De la transmission, de la continuation… et du plaisir

Un petit plaisir personnel, nous discutions à plusieurs, et j’entendais « Tiens, Untel m’a inspiré en accessibilité », l’autre personne disait « Tiens, Untelle m’a inspirée en accessibilité », etc. et, cette chaine passant par moi, je ne pouvais que sourire, car un de mes mentors en accessibilité était à mes côtés, un certain Laurent Denis. Ce plaisir de faire partie d’une chaine de gens qui se nourrissent, transmettent et partagent de belles valeurs, ça n’a pas de prix.

Curieusement, si mon année a été chaotique, je trouve que cette édition a été plutôt sous le signe de l’apaisement. Deviendrait-on enfin responsables ? :)

J’ai eu le plaisir de faire répéter et d’aider du mieux que je pouvais Lena qui se lançait pour une première fois à parler à Paris Web. Son sujet m’a particulièrement plu, et j’ai été impressionné par la qualité de sa présentation (huhu, ma première présentation était bien moins réussie !).

Plus modestement, j’ai pu aussi aider à la répétition de la conférence d’ouverture, avec Carine et Jean-Philippe, qui ont bien assuré, en dépit du stress pour la première et d’une voix éteinte pour le second. Et distribuer du chocolat. :)

Côté ateliers

Si l’année précédente, j’avais pris quelques claques durant les ateliers, cette année, j’ai été gâté avec l’atelier sur les générateurs de sites statiques. Heureusement que Boris était à mes côtés, sa vision pragmatique et éclairée du sujet m’a fait gagner énormément en vision du sujet. Un vrai mentor, pour le coup.

Cette année, je co-présentais avec Aurélien Lévy sur des composants accessibles. Que dire, si ce n’est que c’est une grande leçon d’humilité. Les questions pleuvent et abondent, et nous ne sommes pas trop de deux pour étancher la soif de connaissance des personnes sur place. J’espère ne pas les avoir déçues. Je me dis qu'il y a énormément de demande là-dessus, peut-être une idée pour l'année prochaine ?

En fin de journée, j’animerai un atelier sur CSP.

Je craignais d’avoir un public très avancé sur le sujet, et j’avais prévu beaucoup de choses de peur de ne pas contenter ce public. Finalement, je me suis rendu compte que j’avais presque trop prévu. Le sujet en filigrane sera la difficile maitrise du front-end et des contenus. Finalement, les questions viendront au fur et à mesure. J’espère ne pas avoir trop effrayé et trop mis le paquet sur ce sujet.

Pour aller plus loin

N’en déplaise aux râleurs, ce genre d’événement est et reste incontournable. Nous sortir de notre quotidien ou de nos spécialités, nous retrouver entre gens passionnés, c’est non seulement plaisant, mais c’est indispensable. Enrichissant, inspirant. Voir autant de sourires, de gens qui se comprennent, qui vivent les mêmes galères et qui pourtant veulent mieux pour le Web, qui veulent un Web plus responsable, pour reprendre le thème de cette année.

Je pense sincèrement qu’on ne réalise pas l’importance de ces événements… ou malheureusement trop tard. Derrière chaque grande idée, il y a un moment des personnes qui se sont levées, et qui ont dit « et si on faisait quelque chose » ou « nous pouvons faire quelque chose ». « Et si… » sont deux mots qui peuvent emmener loin. Même si la tâche parait impossible. Ce petit monde ouvert, progressiste, bienveillant, inclusif, passionné, drôle, etc. où il fait bon se retrouver chaque année, je l’aime profondément et je veux le voir vivre encore, continuer d’essaimer des idées et tout simplement être toujours meilleur.

Je ne saurai lister exhaustivement tout ce que Paris Web m’a apporté, au long des éditions auxquelles j’ai pu participer, et suite à tous les à-côtés qui en ont découlé. J’ai eu le plaisir d’être plus proche du staff cette année, même si ma contribution fut extrêmement modeste. Il est temps pour moi de rendre à Paris Web ce que cela m’a amené.

Je ne sais pas encore sous quelle forme, mais cette conclusion est une lettre de motivation : les gens du staff, vous êtes des personnes inspirantes. Vous forcez mon admiration et mon respect. On cite souvent les conférences, mais il y a une injustice profonde, on ne vous rend pas assez hommage, même si vous avez eu la standing ovation à la fin des conférences, et c’est bien un minimum. Surtout que vous n’avez pas été épargnés, le chemin a été semé d’embûches. Et non seulement vous avez réussi, mais en plus ça a poutré des coincoins. Encore bravo et merci !

Si j’ai beaucoup rodé avec vous cette année, c’est aussi pour cette raison : je veux vous rejoindre, je veux apprendre à vos côtés, je veux contribuer à faire vivre ce petit monde où il fait bon se retrouver chaque année… amour gloire et beauté, des mots qui font rêver (oui, je vais ramener ma connerie avec, si vous voulez bien de moi).

Je veux me lever et dire « Je peux faire quelque chose ». Même si en toute honnêteté… j’ai tout à apprendre.

Amélioration progressive et bugs sont dans un bateau… (le 18/09/2017)

Tomber sur un bug navigateur, c’est être subitement atteint de schizophrénie. D’un côté, vous êtes super-fier d’avoir mis la main sur un des Saint-Graal du développeur (« hé, c’est la classe, t’as vu, j’ai trouvé un bug dans le navigateur »), et de l’autre, en réaction primaire, vous êtes limite en pétard contre le navigateur en question.

Colère !

Si ce dernier n’est pas votre navigateur préféré, il est probable que des insultes d’oiseaux fusent. Par contre, si c’est votre préféré… c’est un peu comme si vous preniez votre grand amour dont vous êtes transi-love-hashtag-inférieur-à-3 sur le fait en train de se curer le nez… ça n’est pas terrible. On ne va pas se le cacher, en tant que personne très proche du Web, le choix du navigateur a un petit quelque chose d’irrationnel, le même genre de réaction qui vous pousse à fustiger les autres navigateurs.

C’est humain, quel client n’a jamais pesté contre une agence web pour une indisponibilité du site ? (alors que ladite agence ne gère pas l’hébergement)
Et ces réactions, bien que très humaines, sont souvent… bien à côté de la plaque.

Une histoire assez surprenante m’est arrivée récemment avec deux de mes sites et un bug navigateur.

Pas plus tard qu’il n’y a pas longtemps, je constate que la dernière version de Firefox n’affiche pas tout à fait correctement la documentation des scripts sur le site Van11y (le JavaScript n’est pas exécuté). Le problème semble venir du contrôle d’intégrité (SRI) mis en place. Le bug est extrêmement étrange, en faisant un Ctrl+F5, le tout refonctionne bien, et en faisant un simple F5, le bug persiste (???). Même symptôme sur le site de Röcssti sur certaines pages.

Je vérifie que le contrôle d’intégrité est juste, c’est bien le cas. Bizarre.

Là, je commence à prendre peur, j’ai déployé SRI sur d’autres sites en production au travail… mais aucun n’est impacté. La seule différence fondamentale entre les sites impactés et ceux ne l’étant pas est… l’utilisation de Service Workers.

Bref, je demande à d’autres personnes pour savoir si le problème n’est que chez moi. À priori, c’est le cas chez certains, et on le reproduit au boulot. Julien ouvre un bug avec un exemple minimal pour reproduire le bug, et là, la discussion va être surprenante.

Your outer <script> tag is generating a no-cors Request which is not allowed to have an integrity value when it gets passed through to fetch().

You are not seeing the message about this because the service worker script catches the TypeError and converts it to offlineAsset(). Of course, offlineAsset() does not match the outer integrity check.

Il se trouve que c’est bien l’utilisation conjointe de SRI et des Service Workers qui crée le problème… mais pas exactement comme on pouvait le penser. Sans rentrer dans les détails (que moi-même j’ai du mal à suivre), l’utilisation conjointe de fetch(), des Service Workers, de SRI et le tout saupoudré de CORS (!!), bref, tout ce petit monde crée selon la spécification les conditions qui font que le calcul d’intégrité est voué à foirer.

On pourrait croire que Firefox est en faute…

The reason this does not happen in chrome is because they have not implemented Request.integrity yet. Once they do chrome should fail in the same way.

… sauf que ce n’était pas une erreur, mais une feature. C’est parce que Firefox avait implémenté des choses en plus selon la spécification que le problème est apparu. Coquin de sort.

D’ailleurs, un bug a été ouvert dans la spécification de fetch(). Autres morceaux choisis :

Note, we are going to move forward with this fix since its impacting sites.

Cela, c’est le genre de message qui fait plaisir à lire quand on est impacté. Vraiment. Et la légendaire non-amabilité des développeurs vient de prendre un coup dans l’aile.

Once that’s done I’ll merge this since Chrome hasn’t implemented integrity yet it sounds like and they probably want to do the same as us.

Si vous croyez que c’est toujours la guerre entre les personnes qui développent les navigateurs, loin de là. Entre leurs fans, je ne dis pas, mais c’est autre chose.

Finalement, le bug a été patché et le patch sera publié dans deux versions de Firefox, soit vers mi-Novembre. Une affaire efficacement menée, et en plus, je sais que Chrome n’aura pas ce problème, comme les autres navigateurs. Du coup, j’ai fait la seule chose à faire dans les 2 bugs (spécification et navigateur), j’ai simplement dit merci.

Tout cela m’inspire la réflexion suivante : on parle souvent de l’amélioration progressive et de ses bienfaits. Loin du fanboy-isme autour de cette méthode, j’entends souvent que concevoir en amélioration progressive est un stress supplémentaire, et compliqué. Cela peut être vrai, mais j’y vois une tranquillité supplémentaire : en amélioration progressive, on ne se pose pas la question de savoir si le problème va arriver, mais simplement quand il va arriver. Et du coup, les sites sont parés à cette éventualité. Même si cela peut être rare, cela peut toujours arriver.

Là, je suspecte que les JavaScripts de mes sites ont sauté depuis la dernière version de Firefox, dans l’absolu, j’aurais pu complètement passer à côté sans que cela n’impacte leur fonctionnement. La documentation impactée est toujours lisible.

Certes, j’aurais pu enlever SRI de mes sites… mais pourquoi après tout ? Ils marchent quand même. Réfléchissez aux nombres de sites pour lesquels vous pouvez dire cela.

Les langages hermétiques : FF, a11y et mansplaining (le 30/06/2017)

Peut-être connaissez-vous ce sketch assez épique des Inconnus : Les langages hermétiques. Si vous ne l’avez jamais vu, je vous conseille de le regarder de suite, vous risquez de vous prendre quelques fous rires.

Même si je suis raisonnablement informé… il m’arrive d’être complètement, totalement à côté de la plaque, à l’instar de ce Monsieur Gentil dans ce sketch. En voici trois exemple :

Quand je suis arrivé sur Twitter, je reçois des « #FF » me mentionnant. De la part d’hommes et de femmes. J’avoue avoir buggé. « #FF » veut dire Follow Friday. C’est une coutume de Twitter de recommander des gens à suivre le vendredi.

Sauf que cela, je ne le savais pas au début. L’abrévation « #FF » avait un autre sens pour moi… « Fuck Friend ». Littéralement ami à baiser, je vous laisse lire la page de Wikipédia si vous ne connaissez pas. Imaginez ma surprise. Bon, rien de grave, un quiproquo amusant qui n’a pas duré.

Autre exemple, j’ai toujours adoré le sujet de l’accessibilité. Et pleins de gens, toujours sur Twitter, parlaient et me parlaient d’« a11y ».

A-onze-y ? Ally (Mc Beal, si si j’y ai cru) ? (le colonel) Atty ? Aïïe-y ? (oui, j’ai tout envisagé, même la douleur, souvent l’accessibilité, ça pique les yeux quand on récupère certains sites)

Bref, c’est après que j’ai su que le 11 était pour indiquer que 11 lettres manquaient pour faire Accessibility. Ironique, non ? J’ai été mis en situation de handicap à propos d’accessibilité. Ceci dit, rien de dramatique non plus.

Plus récemment, il y a quelques mois, je vois passer les mots « manspreading » et de « mansplaining ». Comme je parle – à peu près – correctement anglais, je compris immédiatement le sens du premier anglicisme, soit l’habitude très peu polie – carrément mal élevée – qu’ont certains hommes à s’étaler (notamment en écartant les jambes), par exemple dans les transports en commun (où l’on peut être vite à l’étroit).

Et pour le mansplaining… coquin de sort, je dois vous expliquer mon raisonnement. J’ai cru en toute bonne foi qu’on parlait avec plaining de se plaindre (plaining/complaining ça se ressemble, en tout cas suffisamment pour mon niveau d’anglais), soit de se plaindre de quelque chose. Et j’ai cru dur comme fer pendant des mois et des mois que c’était le sens de ce mot. Le pire, c’est que cela collait avec pas mal de situations où je voyais ce mot utilisé.

Sauf que… pas du tout. Je cite Wikipédia : Le mansplaining désigne la situation où un homme (en anglais man) se croit en devoir d’expliquer (en anglais explain) à une femme quelque chose qui la concerne directement, généralement de façon paternaliste ou condescendante. Le sens est vraiment différent !

Bon, rien de dramatique non plus, dommage que je ne sois pas tombé sur la tentative de transposition en français « Mecsplication », qui pour le coup m’est bien moins ambigüe. :)

Bref, je vous passe d’autres exemples du genre, sinon ce billet pourrait être bien long.

Je pourrais essayer d’expliquer cela avec une tentative de dés-ambiguïsation des mots, d’inclusivité, etc. mais cela risque d’être trop verbeux et maladroit. Et surtout, Sébastien Desbenoit l’a verbalisé bien mieux que moi : attention, nous ne vivons pas sur la même planète (sémantique, compréhension, etc.). Lisez ce billet, cela en vaut vraiment la peine.

Si l’on peut en rire, partagez vos quiproquos et autres incompréhensions, cela ne fera de mal à personne.

« Je hacke le retour d’expérience via un phrasé velouté » (Sud Web) (le 22/05/2017)

Il est dit dans les temps anciens, il y a de longues Décades,
Que chaque homme s’accomplit aux côtés de ses frères d’armes.
C’est mon idéal de chevalier de la Sainte Cascade,
Descendant vers le Sud, dont les chemins me charment.

Je n’ai pas été de toutes les croisades itinérantes,
J’ai pris part à certaines qui furent vibrantes,
Qui tels des héros me firent endosser leur cape.
Par contre, point d’adoubement dans la cité des Papes,
D’un curieux ménestrel venant d’une étrange crypte,
Qui se plaint de la difficulté… des dates en JavaScript ?!

Me voici loin de ma Borée, dans cette province nommée Provence,
À la recherche d’une bienfaisante et douce providence,
Appréciant l’accueil agréable, par une délicate et apaisante ablution,
Ne manquaient que les Dames du Lac, qui de mon bonheur font la complétion.

Je fus venu avec mes forces et quelques certitudes,
Espérant étudier le docte parchemin des workers,
Çà et là la structure des Fermetures – qui m’est bien rude,
Ou bien la Conception Universelle, si chère à mon cœur.
Que nenni, rien de ces secrets ne me fut enseigné !
Mais les leçons furent ailleurs, de mon mal je fus saigné.

Lors de l’assemblée autour de la manquante table ronde,
J’en fus plutôt coi, mes frères d’armes n’ont pas d’armes,
Ou en tout cas plutôt celles d’une douce force calme,
Et voilà que mon armure telle une porte se dégonde.

Je m’incline donc bas devant mes frères et sœurs d’armes,
Dans mon cœur ont pris place, en ont délogé les larmes.
Voici que ma prose s’emballe, je sème vers à tous vents,
Tout ce qui a un début a une fin, voici un commencement :
Prenez mon âme, du moins un petit morceau, partagez-la,
J’en ferai de même avec vous, notre richesse sera là.

Ne voyez pas de vanité dans la forme, plus une liberté
Que je m’offre prestement, ce sera mon butin !
Je hacke le retour d’expérience via un phrasé velouté,
Mais ne manie le vers en aucun cas pour être au thym.
Mon parchemin digital – pardon numérique – s’étiole,
Partageons l’amour, il n’y a rien à perdre, sans fariboles !

In fine, je repars avec moult questions et autres turpitudes,
Néanmoins émerge en moi une indéfectible certitude :
Sans vous – sans toi – je ne suis ni entier ni accompli,
Laissez-moi donc en conter la beauté qu’en vers je brode,
Qui en ce moment me fait toucher un brin d’infini,
Point de délirant péché d’hybris, juste une ode.

Ne me demandez donc pas de ne pas avoir de pleurs,
Car toutes les larmes ne sont pas un malheur.
J’en arrive à l’évidente et simple conclusion
Que je suis submergé par une vague d’émotion.

Vous êtes désormais mon Élysée, mon petit coin de paradis,
ma seconde vie une fois finie, vous serez de ma théogonie,
votre humble serviteur n’a de mot assez beau ici,
alors pour tout ceci, je vous laisse un simple et vibrant…

merci.

Note de lecture : Qualité Web, la référence des professionnels du web (le 06/02/2017)

Cela fait des années que je suis le projet Opquast (pour Open Quality Standards), si vous en doutez, voici ce billet antédiluvien qui parle à l’époque des temps anciens d’un projet intéressant à suivre.

Un peu d’histoire

Historiquement, le projet a connu son premier référentiel en 2004, j’avais pu participer modestement à sa création. La version 2 était arrivée quant à elle en 2010, je n’avais pas pu y participer pour tout un tas de raisons. La version 3 est arrivée en 2015, et là, j’ai pu me faire plaisir en proposant, discutant lors de longs échanges passionnants avec les contributeurs du projet.

Le premier livre est sorti il y a 5 années, et c’était un bon cru, comme ce billet le disait : Qualité Web, le livre, première édition.

Alors, posons la question clairement. Qualité Web : stop ou encore ?

Qualité Web, les bonnes pratiques pour améliorer vos sites

Cette nouvelle édition s’organise différemment de la précédente :

  • la première partie présente les bases de la Qualité Web et de son management ;
  • la deuxième partie contient toutes les fiches dédiées aux 226 bonnes pratiques ;
  • la troisième partie présente les autres checklistes (SEO, performances, etc.) ;
  • la dernière partie est une boite à outils pour tous les professionnels (glossaire, outils, références, etc.)

Durabilité

Là c’est mon côté pragmatique qui va vous faire remarquer que ces bonnes pratiques ont un point fort : elles vieillissent très bien. 29 ont été abandonnées ou transformées en recommandations depuis le précédent référentiel, ce qui correspond à environ 13 %. C’est extrêmement peu, pour ne pas dire que dalle.

Vous en connaissez beaucoup des bonnes pratiques que vous pratiquez depuis plus de 10 ans et que vous n’avez pas abandonnées ? Nos métiers ont énormément changé, les pratiques aussi. Et pourtant, ces bonnes pratiques restent là, presque en pied de nez à l’évolution parfois insolemment rapide. Et très peu ont été totalement abandonnées, la plupart ont été placées en simples recommandations (de bons conseils, à garder à l’esprit si elles sont applicables).

Ces bonnes pratiques ne s’intéressent pas aux technologies ni à des objectifs chiffrés, selon les désormais célèbres 10 règles du contributeur Opquast.

Un livre multi-publics

En général, vous ne lirez pas ce livre comme je l’ai fait, c’est-à-dire intégralement (privilège du relecteur). :)

Non pas que je vous déconseille de le lire en entier – c’est très bien écrit et très intéressant – mais selon votre profil ou votre besoin, vous aurez peut-être juste le besoin d’aller consulter une partie (par exemple e-commerce) ou de simplement apprendre d’autres bonnes pratiques.

Ne vous arrêtez pas au côté impressionnant du livre : les bonnes pratiques sont sur des fiches très simples et dans un format très pratique.

Un livre qui diminue « le prix du ticket d’entrée »

En tant que profil ayant plusieurs années d’expérience, j’ai parfois tendance à oublier que des choses qui me sont acquises sont loin de l’être pour des personnes débutantes. Et avec l’explosion des compétences qui partent tous azimuts, il est facile de vite se retrouver débutant. Certains choix techniques ont un coût d’entrée quand on débute qui n’est pas simple.

Quoi qu’on en dise, maintenir un socle d’objectifs, de connaissances et de culture générale aide à garder un ticket d’entrée aussi bas que possible pour travailler sur et dans le Web, et cette idée me plait toujours plus. Les fiches sont écrites dans un langage clair, accessible et précis, et ça fait du bien, bordel !

Disons-le clairement, ce livre ne fera pas de vous un génie dans une technologie donnée, mais ce que j’apprécie, c’est qu’il contribue à nous ramener à l’essentiel : s’occuper des risques et servir les utilisateurs (qui eux se moquent bien qu’on utilise telle ou telle technologie).

Le renforcement de certains domaines

Le mobile et les formulaires se voient étoffés dans cette nouvelle édition. La sécurité se voit également considérablement étoffée pour cette version, en-têtes de sécurité (x-content-type: nosniff, x-frame-option, CSP, etc.). Aller tester un site sur Mozilla Observatory, et vous comprendrez pourquoi ces bonnes pratiques y sont entrées. Mon petit doigt me dit que l’on n’a pas fini de parler de ces sujets de sécurité cette année !

Conclusion

Stop ou encore ? Clairement, encore. Et même plus que jamais. Des années que ces bonnes pratiques tiennent la route et nous guident vers une montée en compétence (et en qualité !), et accessoirement nous permettent de rendre durable notre écosystème.

La marque Opquast s’impose comme la référence, donc autant le dire clairement, si vous croyiez que le titre était un peu mégalomane… il n’en est rien. C’est clairement la bible des professionnels du web, et donc « la référence des professionnels du Web  ». En toute simplicité. Il pose aussi les bases de métiers en voie d’apparition : responsable Qualité Web.

Ce n’est pas pour rien que je suis ce projet depuis le début, et que je compte continuer de m’y impliquer. Bravo la team Temesis et tous ceux qui ont participé à l’écriture de ce bien bel ouvrage !

Pour trouver ce livre incontournable : Qualité web – Le livre, la référence des professionnels – 2e édition.

Bilan 2016 et perspectives 2017 (le 07/01/2017)

2016 s’est terminée il y a peu, et en lisant le bilan de @hellgy, je me suis dit que ce ne serait pas une mauvaise idée de faire de même. À la fin 2016, j’avais l’impression de n’avoir pas fait énormément de choses, et en relisant, je me dis que cette année n’était pas un si mauvais cru… en tout cas pas si horrible et totalement à jeter comme on nous l’a vendue.

Des peurs et du trop plein

Je crois que 2016 a été suffisamment anxiogène (attentats, etc.), c’est la première année où je me suis surpris à éteindre la radio (un des rares médias que j’écoute bien volontiers en allant et revenant au travail) en disant « stop, j’en peux plus ». Finalement, l’info en continu/temps réel, c’est bien, mais sur des événements qui tapent à l’émotionnel, c’est pas indispensable. Et on s’évite souvent les âneries fausses de journalistes/politiques en mal de matière pour meubler…

Idem côté réseaux sociaux, les (non-)infos relayées à la va-vite sans aucune vérification me font fuir. Sur Facebook, c’est proprement horrible le nombre d’âneries qui sont relayées sans vérifications (et idem sur d’autres réseaux sociaux). Ajoutons à cela qu’un paquet de gens sont dans la pure posture, il est donc difficile voire impossible de discuter avec. Maintenant, je fuis ce genre de trolls.

Même si je suis toujours bon appréciateur de Twitter, j’ai réduit le temps que j’y passe et le volume de tweets. Et de manière encore plus drastique pour Facebook. Par contre, je me suis récemment remis à IRC, et… au bon vieux mail pour de délicieuses correspondances. :)

Des réalisations et des projets pas si mal

Même si j’ai eu la sensation du contraire, j’ai pu participer à des projets très intéressants, notamment la refonte du Directory d’ESOMAR et d’autres projets. Röcssti a tourné la barre des 100 sites réalisés, et encore, je suis à la bourre pour la mise à jour de la galerie, d’autres ont été mis en ligne aussi. :)

Et il y a le lancement de Van11y. Ok, ces scripts sont des versions 1.0, totalement imparfaites, mais c’est un début, et il vaut mieux commencer imparfait que de ne rien faire.

Ajoutons à cela que je me suis improvisé relecteur/correcteur pour la deuxième édition de Qualité Web - Le livre, du coup, j’ai mêlé l’utile à l’agréable, en quelque sorte. Je ne pensais pas tant aimer faire le relecteur.

Des articles et des billets

Cette année, côté articles, ce n’était pas mal non plus :

Côté billets sur ce site, c’était pas si mal non plus, je retiens :

Parmi d’autres.

Des conférences et des gens

Vraiment, c’est le meilleur de cette année. Une année standard, c’est habituellement la possibilité de participer à deux conférences maximum pour moi (temps libre très limité, oui, j’assiste aux conférences sur mes vacances !). Cette année, j’ai pu participer à 3 conférences : Sud Web, Paris Web et Codeurs en Seine. 3 sujets en tant qu’orateur pour 2 conférences, c’est déjà bien.

Ces 3 événements étaient super, chacun avec ses bonnes idées et ses bons moments, j’ai pu connaitre de nouvelles personnes, en revoir d’autres que j’aime beaucoup, et même tisser des liens très forts. Sans parler des sujets, j’ai de quoi apprendre pour au moins tout 2017. :)

En plus, autant j’ai été le débutant sur bon nombre de sujets (et témoin d’énormément de bienveillance en tant que), autant j’ai pu accompagner des personnes sur d’autres. Vraiment ces moments restent parmi les meilleurs de 2016, je me languis d’en revivre de tels. Laissez-moi être votre débutant !

Sur le plan personnel

J’arrive à environ un peu plus d’une semaine supplémentaire à la fin de l’année, environ 50 heures. Un des progrès pour cette année 2016, cela a été lissé sur toute l’année, je n’ai pas eu un mois à bosser comme un taré à faire plusieurs semaines à 60 heures. J’espère bien continuer cette régularité. Et surtout la reprendre pour les projets à côté, j’ai été trop irrégulier en 2016.

Côté personnel, vous ne m’en voudrez pas de ne pas détailler plus. Sachez juste que c’est contrasté.

Pour 2017, des idées en vrac

Plus aider les initiatives

J’ai jamais eu aussi peur que de bonnes choses puissent s’arrêter (événements, initiatives, etc.). Cela a déjà été le cas pour Firefox OS et d’autres, et j’en ai marre de voir de bons projets sacrifiés et des choses bien qui s’arrêtent. Pour ça que je compte soutenir plus ouvertement et même financièrement des initiatives (Let’s Encrypt, La Quadrature du Net, Wikipedia, Paris Web, et d’autres…).

Moins de silos…

La première chose qui m’importe, c’est de continuer à dé-silo-iser certains aspects, et principalement dé-Googliser un paquet de trucs. Je pense que certains de mes sites vont dégager Google Analytics et plutôt utiliser des Piwiks auto-hébergés. Pour mes besoins, c’est largement suffisant, j’ai testé ça sur Van11y, c’est parfait.

Toujours dans cette idée, je suis passé à Qwant au travail et à la maison, et croyez-le ou non, ça fonctionne très bien et cela suffit largement à mes besoins et les résultats sont très pertinents.

J’étais déjà pas un fanatique de Medium, mais une expérience à la limite du dark pattern m’a refroidi de l’utiliser pour longtemps. Facebook me fatigue, j’ai dû faire disparaître la moitié ce que publient les gens, quand ce ne sont pas les gens eux-mêmes.

…Ou du moins les remettre à leur place

Je n’ai rien contre les réseaux sociaux en particulier, néanmoins l’expérience de Nowwwel que Rémi voit avec un petit pincement au coeur, je trouve que c’était un régal : les gens ont écrit (beaucoup), et ont partagé. En clair, j’aimerais bien que Nowwwel, ça soit toute l’année. J’ai de nouveau envie d’écrire, que ça soit ici ou ailleurs. J’espère que d’autres vont retrouver le plaisir de publier chez eux aussi. Remettons les réseaux sociaux à leur place, en simples caisses de résonance !

Du Fact-Checking

Ne comptez pas sur moi pour faire suivre des âneries, surtout que cette année se profile une présidentielle qui risque d’être abracadabrantesque, comme disait l’autre.

Parlez-moi de données vérifiées, croisées, de discours argumentés, de non-manichéisme, d’humilité, d’honnêteté intellectuelle et de prudence dans le propos. Typiquement, j’ai beaucoup les vidéos de Hacking social (leur dernière vidéo sur l’effet Julien Lepers vaut vraiment le détour) ou de Hygiène mentale, qui parle de zététique (visionnez celle sur les arguments fallacieux, qui vaut aussi le détour).

La sécurité

Comme mentionné plus haut, le sujet de la sécurité des sites me passionne, je m’éclate comme un gosse à apprendre sur ces sujets. Mozilla Observatory est un projet fantastique qui m’a énormément appris.

J’ai pas fini d’écrire et de faire des trucs sur le sujet, autant vous le dire de suite !

Apprendre et continuer les projets

Cette année est vraiment intéressante : avec les PWA, de nouvelles API, plein de nouvelles choses sur la sécurité, et tout le reste… on ne va pas s’emmerder !

Mes petits projets comme Van11y, les plugins accessibles (ou d’autres…) vont sûrement progresser, pas aussi vite que je le voudrais, mais c’est un de mes objectifs.

Et je place aussi l’objectif… de ne rien prévoir. Se laisser du temps libre pour découvrir, c’est très bon aussi !

Conclusion

Je pensais avoir très peu écrit/fait de choses cette année, refaire ce bilan me montre que mon sentiment est plutôt faussé. Faites ce bilan aussi si jamais vous avez l’impression de ne pas avoir fait grand chose.

Et surtout, accordez-vous du temps, le droit de ne pas faire parfait, le droit de ne pas tout savoir, le droit de ne pas être au top, le droit de ne pas être dispo 24H/24, le droit de demander de l’aide.

Et des gens, de l’amour et du bon temps partagé, en toute simplicité. C’est le plus important.

Les bonnes résolutions de l’entourage des travailleurs du web (le 22/12/2016)

Pour l’initiative de Nowwwel, j’avais pensé écrire un truc très inspirant et sérieux, et… ça sera pour la prochaine fois.

À la place, rions un peu en cette presque fin d’année où il est souvent question de bonnes résolutions : j’ai imaginé ce que seraient les bonnes résolutions… des entourages proches (familles, amis, etc.) des personnes travaillant dans le Web (ou plus largement dans l’informatique), enfin de certains de ces entourages. Oui, les gens qui ne connaissent pas forcément bien nos métiers, nos vies, etc.

Bien évidemment, toute ressemblance avec des personnes existant ou ayant existé… est absolument fait exprès !

Je vous invite à rêver d’entendre votre entourage vous dire cela :

  • Oui, je ne dirai plus que tu passes ton temps à buller sur Internet.
  • Je promets de tenir la première résolution. Si si.
  • Promis, juré.
  • Et… oui, je ne dirai plus non plus que ton job consiste à lire des e-mails.
  • Oui, je ne dirai plus que ton métier n’est pas un vrai métier parce que tu ne lèves pas 50 kilos de ciment ou tu ne laboures pas un champ.
  • Corolaire : je ne ferai plus de remarque déplaisante du genre « Tu passes ton temps sur un ordinateur, tu ne peux pas être fatigué ». Promis.
  • Corolaire : j’ai compris que ta relative jeunesse n’empêche pas la fatigue et même l’épuisement.
  • Oui, tu as un humour et une culture qui me semblent particuliers, mais non, je ne dirai plus systématiquement que ce ne sont que des « blagues d’ado attardé ».
  • Non, je ne te suggèrerai plus jamais de « faire tomber de la neige sur ton site » !
  • Je ne te dirai plus que tu devrais faire comme sur Facebook ou autre, car j’ai compris que le budget de ton projet/équipe est sûrement différent.
  • Oui, j’ai vraiment compris que le fait que tu travailles avec un ordinateur n’implique pas que tu en maitrises toutes les arcanes.
  • Corolaire : oui, tu n’es pas un spécialiste de l’installation des imprimantes.
  • Corolaire : j’ai aussi compris que tu n’es pas un spécialiste du dépannage informatique.
  • Corolaire : j’ai également compris que le dépannage informatique t’emmerde profondément, même si tu n’oses pas me le dire.
  • Corolaire : je ne profiterai plus de cette excuse pour te demander de faire n’importe quelle tâche en ligne à ma place.
  • Je prendrai des notes de ce que tu m’expliques, afin d’éviter de te demander 20 fois la même chose.
  • D’ailleurs, si je te demande conseil, j’écouterai ce conseil.
  • Corolaire : d’ailleurs, j’arrêterai de me plaindre devant toi des conséquences du non-respect de tes conseils.
  • Oui, je comprends que travailler dans le Web nécessite que tu apprennes constamment.
  • Même si je n’y connais rien, oui, je comprends que tu n’exagères pas en disant que tu dois te tenir à jour quotidiennement.
  • Corolaire : je te permettrai donc d’apprendre, en te laissant aller à des formations/conférences/meet-ups/etc.
  • Corolaire : oui, j’ai compris que tu dois compter majoritairement sur toi-même pour te former.
  • Corolaire : oui, j’ai compris que tu peux avoir le besoin de parler à des gens de ton métier, fût-ce des inconnus pour moi.
  • Oui, j’ai compris que le fait que tu sois sur l’ordinateur à la maison n’est pas nécessairement un prolongement de ton travail.
  • Corolaire : j’ai même compris que si tu pratiques des choses de ton travail à la maison, cela pouvait te détendre.

Note finale : c’est de l’humour… nous sommes également très loin d’être parfaits.

Dans le même genre :

Ces articles ont été écrits par Nicolas Hoffmann.

Lister toutes les autres news
(long à charger si connexion lente)
Ce site est la propriété de Nicolas Hoffmann. Tous droits réservés.