FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 7, column 106: Self reference doesn't match document location [help]

... rel="self" type="application/rss+xml" />
                                             ^

line 79, column 68: title should not contain HTML:   (2 occurrences) [help]

  <title><![CDATA[ Vous souvenez-vous du futur, deuxième&#8239;? ]]></title>
                                                                    ^

line 183, column 0: description should not contain loading attribute (6 occurrences) [help]
```
Ok, pas de souci, c’est vraiment facile à faire, je prévois de fa ...
```

Source: http://www.nicolas-hoffmann.net/rss/index.php

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="rss.css" type="text/css"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Nico’s dreams - Blog et pensées d'un intégrateur/développeur web - Nicolas Hoffmann</title>
<link>https://www.nicolas-hoffmann.net/rss/index.php</link>
<atom:link href="https://www.nicolas-hoffmann.net/rss/index.php" rel="self" type="application/rss+xml" />
<description>Nico’s dreams - Nouveautés et mises à jour - Nicolas Hoffmann</description>
<language>fr-fr</language>
<ttl>120</ttl>
<pubDate>Tue, 01 Apr 2025 03:18:55 +0200</pubDate>
<lastBuildDate>Tue, 01 Apr 2025 03:18:55 +0200</lastBuildDate>
<managingEditor>contact@nicolas-hoffmann.net (Nico)</managingEditor>
<webMaster>contact@nicolas-hoffmann.net (Nico)</webMaster>
<image>
<title>Nico’s dreams - Blog et pensées d'un intégrateur/développeur web - Nicolas Hoffmann</title>
<url>https://www.nicolas-hoffmann.net/rss/nicos_dreams.jpg</url>
<link>https://www.nicolas-hoffmann.net/rss/index.php</link>
<description>Nouveautés et mises à jour</description>
</image>
<item>
<title><![CDATA[ Une petite surprise à propos de max en CSS ]]></title>
<description><![CDATA[ Je partage une petite mésaventure qui m'est arrivée en <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr>, il est fort probable que je ne sois pas le seul qui puisse commettre de bonne foi cette erreur.
L'autre jour, je me retrouve à utiliser <a href="https://developer.mozilla.org/fr/docs/Web/CSS/max">max</a> en <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> pour effectuer une adaptation de <a href="https://calendar.proton.me/">Proton Calendar</a> pour des écrans gigantesques (ou si on dézoome fortement).
Grosso modo, le code en question est (le détail de la valeur n'est même pas important) :
<pre><code>block-size: max(3rem, calc((100lvh - 3.75rem - 4.75rem) / 24))</code></pre>
En clair, prends-moi la valeur maximum entre les deux valeurs, ce qui m'assure que si l'écran n'est pas gigantesque, l'élément en question fera au moins <code>3rem</code> quoi qu'il arrive. Rien de bien extraordinaire, je me dis que c'est même assez <abbr title="à l'épreuve des balles">bulletproof</abbr> — en anglais dans le texte, construit ainsi en amélioration progressive. Personne ne trouve à redire.
Quelques jours plus tard, je reçois des retours, quelques utilisateurs ont des soucis. J'investigue un peu, et je me rends compte que ce sont de vieux navigateurs qui pêchent (des Firefox/Chrome 87 ou des Safari 15.x). Là, j'avoue que je suis surpris : cette syntaxe me parait pourtant à l'épreuve des balles. Quand bien même les navigateurs ne supporteraient pas l'unité <code>lvh</code>, <code>max</code> entre <code>3rem</code> et un truc pas supporté, c'est <code>3rem</code> qui gagne, logiquement.
Je fouille un peu dans <a href="https://drafts.csswg.org/css-values/#comp-func" hreflang="en">la spécification</a>, ouvre <a href="https://github.com/w3c/csswg-drafts/issues/11768" hreflang="en">une question sur le CSS Working group</a>, et là… <a href="https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation" hreflang="en" lang="en" xml:lang="en">surprise motherf*****</a> !
En fait, si une des valeurs renvoie <code>failure</code>, l'intégralité de l'expression renvoie <code>failure</code>. En clair pour mon cas, si les <code>lvh</code> ne sont pas supportés, kaboom, la comparaison avec <code>max</code> foire totalement !
J'avoue avoir été surpris ! Ceci dit, le fix a été simplement d'entourer la version avec un <code>@supports</code> avec ce qu'il faut dedans :
<pre><code>block-size: 3rem; @supports ( block-size: ( max(1rem, 100lvh) ) ) { block-size: max(3rem, calc((100lvh - 3.75rem - 4.75rem) / 24)) } </code></pre>
Comme quoi, on a toujours des surprises… ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1723-Une-petite-surprise-a-propos-de-max-en-CSS.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1723-Une-petite-surprise-a-propos-de-max-en-CSS.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Tue, 04 Mar 2025 15:11:37 +0100</pubDate>
</item>
<item>
<title><![CDATA[ Bref, j’ai fait une miam-list ]]></title>
<description><![CDATA[ Fin 2022, lors d’une discussion après le repas du 31, tombe le sujet des bonnes résolutions.
Marronnier par excellence, mais j’avoue que je n’ai pas vraiment d’idées. Et puis bon, les bonnes résolutions… je sais très bien que je ne vais pas forcément les tenir sur la durée.
Me vient une idée pas sortie de la cuisine à Jupiter (Coluche) : je balance à mes proches que je ne prendrai aucune bonne résolution, mais que je vais me faire une miam-list. En clair : une liste de trucs que je dois cuisiner maison durant l’année suivante.
Cela peut être des choses simples, ou des choses nécessitant plus de travail. Bref, je teste, et le concept m’a bien fait marrer : 
<ul><li>C’est rigolo (et ça me détend, pas besoin de <code>npm install</code> pour cuisiner…)</li><li>Cela ajoute diverses cordes(ons bleus ?) à mon arc de père isolé</li><li>Et vu les gourmands qui m’entourent… je sais que l’initiative sera suivie et appréciée. J’ai eu des demandes même.</li></ul>
Celle de 2023 a été plutôt un succès : une vingtaine de plats/pâtisseries préparées sur la liste, quelques uns non-faits, un ratage en tout et pour tout, et avec des rajouts en impro.
En langage chef de projet : complétion des <abbr title="Objective, Key Result" lang="en" xml:lang="en">OKR</abbr>s supérieure à 80%, avec des items non planifiés (t’as vu, ça claque).
Bref, je renouvelle cela en 2024, toujours amusant, et j’en arrive à celle pour cette année.<div><img src="https://www.nicolas-hoffmann.net/images/divers/miam-list.jpg" width="400" height="300" alt="Miam-list de Nico" /></div>Liste plus ambitieuse que l’année précédente, cependant avec des éléments vraiment faciles… 
Et comme toute liste, le premier a avoir été fait a été… un non-prévu — on frise vraiment la métaphore chef de projet là ! ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1722-Bref-j-ai-fait-une-miam-list.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1722-Bref-j-ai-fait-une-miam-list.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Wed, 22 Jan 2025 15:54:16 +0100</pubDate>
</item>
<item>
<title><![CDATA[ De l’humilité pour les applications addictives ]]></title>
<description><![CDATA[ Je retrouve de vieilles notes et autres pensées, alors je vais les publier petit à petit. Précision pour celle-ci, elle a été écrite avant le rachat de Twitter par le zinzin qui le possède actuellement — et avant que bon nombre de gens l’aient fui. Et oui je dis Twitter, car le nouveau « nom » pourrait changer quelque peu le sens de la phrase suivante, et… ce nom nouveau est débile.
Retour dans un passé pas trop lointain.
J’avoue, j’étais assez accro à Twitter. Notamment pour la veille, le côté instantané et efficace de chopper de l’info ou de pouvoir pinger des gens, le côté micro-blogging, etc., et toujours un onglet épinglé avec.
Toutefois, plusieurs événements — une <abbr title="Tempête de chiasse intellectuelle">shitstorm</abbr> délirante, une agressivité de plus en plus palpable, etc. — m’ont vraiment fait réfléchir sur le côté détestable/meute enragée des réseaux sociaux.
La problématique était : j’adore Twitter et je dois m’en éloigner, comment faire ?
J’ai pensé à bloquer les personnes les plus virulentes, etc. même si ça calme bien ça ne résout pas le problème. Et une bête idée m’est venue : je repensais à l’expression de Tûtie dite de « la barrière de flemme », notamment évoquée dans une de mes conférences préférées : <a href="https://www.paris-web.fr/2018/conference/tempete-de-boulettes-geantes">la tempête de boulettes géantes</a>.
Et je me suis dit : tiens, et si j’essayais. Virer l’onglet épinglé, virer le raccourci sur le téléphone, ou planquer ce dernier dans un dossier sur la tablette. Mettre le truc à une distance de l’immédiateté, aussi courte soit-elle.
Vous ne le croirez peut-être pas… mais ça marche ! Certes, il m’arrive d’y faire un petit tour de temps en temps, mais cette simple distance évite de gaspiller le temps de cerveau en mode zombie. En gros, il faut faire l’effort d’y aller.
Ensuite, je me suis lancé quelques règles débiles, notamment « au troisième tweet qui en grosse colère contre quelque chose » (justifié ou non, ce n’est même pas la question), je clos l’app. Autant vous dire que celle-ci est vraiment marrante. Si vous avez le <abbr title="Fear of Missing Out" lang="en" xml:lang="en">FOMO</abbr> (la peur de louper quelque chose), elle a tendance à vous en guérir : que vais-je louper ? Bah, de la probable agressivité.
Là où cela m’interpelle, c’est en tant que concepteur d’interfaces — ouais je suis un <abbr title="UX Engineer" lang="en" xml:lang="en">UXE</abbr> — j’entends souvent des discours sur les app addictives, etc. et aussi addictives soient-elles, j’invite les personnes qui conçoivent/possèdent ces apps à avoir beaucoup d’humilité. Aussi incroyable leur design, communauté, expérience, etc. puissent être… elles peuvent être mise au ban pour une simple icône disparue, sur laquelle vous n’avez aucune main mise.
Retour dans le présent.
Bref, au vu de ce que Twitter est devenu récemment, je me dis que finalement, c’était plutôt une bonne idée. :-D ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1721-De-l-humilite-pour-les-applications-addictives.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1721-De-l-humilite-pour-les-applications-addictives.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Wed, 20 Nov 2024 10:14:16 +0100</pubDate>
</item>
<item>
<title><![CDATA[ Vous souvenez-vous du futur, deuxième ? ]]></title>
<description><![CDATA[ Petit préambule. 
Il y a 10 ans, pour fêter l’anniversaire de ce site, je me payais un délire de <a href="https://www.nicolas-hoffmann.net/source/1635-Vous-souvenez-vous-du-futur.html">faire causer mon moi de 2014 avec celui de 2004</a> (autant le relire, car vous risquez de ne pas tout comprendre). Et à la fin, je termine sans réfléchir sur un gag qui fait intervenir mon moi de 2024.
Vous savez ce qui est drôle avec les gags ? C’est qu’ils se réalisent… nous sommes en 2024, et ce blog a 20 ans. Un peu rouillé et attendant une refonte depuis longtemps, mais toujours vaillant.
En emphase, il y aura parfois mon avis, mais quelque chose que je ne peux pas dire sans risquer de faille du continuum-espace temps. Hypothèse la plus pessimiste, le phénomène pourrait être localisé à notre seule galaxie.
Pour simplifier cette histoire de fous, Nico de 2024 sera abrégé <abbr title="Nico de 2024">N24</abbr>, etc. 
<h3>La discussion</h3>
— <abbr title="Nico de 2024">N24</abbr>, tape sur l’épaule : hé, 20 ans, je te raconte pas ! (putain, j’avais qq kilos de plus) — <abbr title="Nico de 2014">N14</abbr> : Nom d’un cul de canard dans ma baignoire !!!!!!!! Je ne veux rien savoir. Rendez-vous dans dix ans.
<abbr title="Nico de 2024">N24</abbr> : dix ans plus tard, c’est là ! (voila, tu voulais faire le gag de la Delorean qui vole dans Retour vers le futur 1, tu l’as bien mérité) <abbr title="Nico de 2004">N04</abbr> : QUOI ?<div><img src="https://www.nicolas-hoffmann.net/images/divers/nico-20X4.jpg" width="300" alt="Meme de Spiderman, avec 3 Nico de 2004, 2014 et 2024 qui se pointent mutuellement" /></div><abbr title="Nico de 2024">N24</abbr> : bah alors vieux, enfin, jeune, on flippe ? (putain, j’avais qq kilos de plus) <abbr title="Nico de 2014">N14</abbr> : pas possible… continuum… (tombe dans les vapes) <abbr title="Nico de 2024">N24</abbr> : hé oui, à défaut de briser le continuum espace-temps, une blague revient toujours à l’envoyeur, cochon qui s’en dédit !
<abbr title="Nico de 2004">N04</abbr> : c’est une blague ? Tu es en train de me dire que ce site existera encore dans 20 ans ??? <abbr title="Nico de 2024">N24</abbr> : et pourquoi pas ? (et merci pour moi jeune con, je passe après le site, sympa le merdeux !)
<abbr title="Nico de 2004">N04</abbr>, en panique : mais mais mais, ça doit être fait avec des technos ultra-modernes et j’ai dû bien le refondre au moins 100 fois ! <abbr title="Nico de 2024">N24</abbr> : mais pourquoi tu cherches compliqué ? Je t’entendais discuter avec l’autre évanoui là, vous… enfin je… bref nous parlions des standards. Tu sais ce que ça veut dire la compatibilité future ? <abbr title="Nico de 2004">N04</abbr> : biiiin, j’ai bien lu <a href="https://openweb.eu.org/articles/pourquoi_standards">un article sur Openweb</a> maiiiiiis…
<abbr title="Nico de 2024">N24</abbr> : mais quoi ? Allez, crache mon petit ! (putain, j’avais des cheveux y a 20 ans) <abbr title="Nico de 2004">N04</abbr> : bin, celui de 2014 avait l’air d’avoir des réserves sur le coup de <abbr title="eXtensible HyperText Markup Language" lang="en" xml:lang="en">XHTML</abbr> et <abbr title="eXtensible Markup Language" lang="en" xml:lang="en">XML</abbr>. <abbr title="Nico de 2024">N24</abbr> : sans trop t’en dire, je peux te dire que cet article ne raconte vraiment pas que des conneries. Évidemment, ça n’évolue jamais exactement de la manière dont on le pense, mais ça c’est normal. Et bien sûr, je ne t’en dirai pas plus. (bin 20 ans après, ça tourne encore, même si plus personne ne connait ce délire, hormis quelques vieux briscards)
<abbr title="Nico de 2004">N04</abbr> : bin merde alors. Dire que j’implémentais un nouveau truc <abbr title="eXtensible Markup Language" lang="en" xml:lang="en">XML</abbr> dont je n’étais pas sûr… <abbr title="Nico de 2024">N24</abbr> : à quoi tu penses ? <abbr title="Nico de 2004">N04</abbr> : bin y a bien ce truc là, j’avoue que je me suis amusé, c’est un peu à la mode, ça s’appelle <a href="http://www.nicolas-hoffmann.net/source/16-Le-fil-RSS-est-pret.html">un flux <abbr lang="en" xml:lang="en" title="Rich Site Summary">RSS</abbr></a>. Ça m’a l’air simple mais je suis pas certain d’en comprendre la portée. <abbr title="Nico de 2024">N24</abbr> : c’est très bien d’essayer des nouveaux trucs. (woupinaise, et dire que c’est peut-être un des trucs les plus beaux qui aient jamais été faits, et dire que je m’en sers encore et que TOUT le monde adore ça même si ça a un peu perdu en visibilité) <abbr title="Nico de 2004">N04</abbr> : ça m’a l’air un peu gadget, j’avoue que j’ai un peu fait comme les autres. <abbr title="Nico de 2024">N24</abbr> : oui, je m’en souviens, t’inquiète. Non, c’est très bien d’essayer des trucs, tu peux me croire. Tu verras bien si ça mord. (au moins les modes étaient moins débiles à cette époque, putain, le gamin il vient de me coller une claque… roooh, je parle comme un vieux con)
<abbr title="Nico de 2004">N04</abbr> : qui vivra verra… putain, 20 ans ! <abbr title="Nico de 2024">N24</abbr> : arrête, on dirait Chirac aux Guignols de l’info (et dire qu’il est mort, les Guignols aussi) <abbr title="Nico de 2004">N04</abbr> : au moins, je me suis amusé à essayer <a href="https://www.nicolas-hoffmann.net/source/52-Un-petit-test-de-la-derniere-mandrake.html">la dernière Mandrake</a>. <abbr title="Nico de 2024">N24</abbr> : héhé, je ne m’en souvenais plus. C’était amusant ces duals boots ? (c’est vrai que je racontais tout et n’importe quoi sur le blog) <abbr title="Nico de 2004">N04</abbr> : oui, avec Mozilla, Firefox 1, et tout le nécessaire.
<abbr title="Nico de 2014">N14</abbr> : (sort des vapes) punaise, ou suis-je ? <abbr title="Nico de 2024">N24</abbr> : j’ai plus l’habitude, faut dire que maintenant que Linux est inclus dans Windows, et Firefox, j’utilise toujours, mais bon, j’ai arrêté de compter les versions après la version 100… <abbr title="Nico de 2004">N04</abbr> : QUOI ? LINUX INCLUS DANS WINDOWS ? Firefox 100 ? <abbr title="Nico de 2024">N24</abbr> : oui, 120 et quelques. Un souci gamin ? Tu es pâle. <abbr title="Nico de 2004">N04</abbr> : (tombe dans les pommes)
<abbr title="Nico de 2014">N14</abbr> : mais sérieux ! Ça va pas de raconter des âneries pareilles ! <abbr title="Nico de 2024">N24</abbr> : héhé… oups ! (bah quoi, j’ai pas menti, le <abbr lang="en" xml:lang="en" title="Windows Subsystem for Linux">WSL</abbr> ?) <abbr title="Nico de 2014">N14</abbr> : et le continuum espace-temps, abruti ? <abbr title="Nico de 2024">N24</abbr> : bin, je me suis dit « on s’en balance », t’aurais vu sa tronche… et la tienne ! <abbr title="Nico de 2014">N14</abbr> : bougre de crétin irresponsable ! Et s’il y reste, on devient quoi nous, t’y as pensé ? <abbr title="Nico de 2024">N24</abbr> : ok, tu marques un point. (putain, se prendre un « irresponsable » de moi plus jeune, ça c’est de l’achèvement)
<abbr title="Nico de 2014">N14</abbr> : déjà que j’essayais de ne pas trop lui en révéler. Tu imagines le choc si je lui parlais media-queries, <a href="https://rocssti.net/">Röcssti</a>, <a href="https://van11y.net/fr/">Van11y</a> ou qu’il va monter sur scène dans les conférences ? <abbr title="Nico de 2024">N24</abbr> : indubitablement. (mon pauvre, je pourrais te faire flipper encore plus !) <abbr title="Nico de 2014">N14</abbr> : et tout s’est <a href="https://www.nicolas-hoffmann.net/source/1507-Paris-Web-une-annee-ombre-a-lumiere.html">un peu précipité y a deux ans</a>. <abbr title="Nico de 2024">N24</abbr> : c’est pas faux.
<abbr title="Nico de 2014">N14</abbr> : au moins, rassure-moi, ça va continuer de progresser ? <abbr title="Nico de 2024">N24</abbr> : par certains côtés oui, par d’autres, je serais plus circonspect. <abbr title="Nico de 2014">N14</abbr> : tu parles de Chrome qui monte inexorablement ? <abbr title="Nico de 2024">N24</abbr> : effectivement, c’est pas la chose la plus glorieuse. À se demander si les gens ont une mémoire. (et c’est encore pire maintenant) <abbr title="Nico de 2014">N14</abbr> : des monopoles comme <abbr title="Internet Explorer" lang="en" xml:lang="en">IE</abbr>6 ? Non. <abbr title="Nico de 2024">N24</abbr> : et pourtant, le gamin avait compris <a href="https://www.nicolas-hoffmann.net/source/1443-Deux-mondes-ne-pouvant-pas-se-comprendre.html">bien malgré lui les dégâts d’<abbr title="Internet Explorer" lang="en" xml:lang="en">IE</abbr>6</a>. <abbr title="Nico de 2014">N14</abbr> : il y <a href="https://www.nicolas-hoffmann.net/source/475-Et-si-la-lente-evolution-du-web-1-2.html">a été confronté</a> oui. <abbr title="Nico de 2024">N24</abbr> : encore maintenant, je m’étonne que rajouter une classe <code>flex</code> puisse résoudre des problèmes par magie. <abbr title="Nico de 2014">N14</abbr> : parle pour toi, je peux pas encore utiliser flex comme un cochon moi ! <abbr title="Nico de 2024">N24</abbr> : (et m…) bah tu peux mais avec des réserves pour les vieux navigateurs. (vite, se rattraper aux branches)
<abbr title="Nico de 2014">N14</abbr> : effectivement. Ceci dit, la communauté se bouge, c’est sympa. <abbr title="Nico de 2024">N24</abbr> : sans aucun doute. (pinaise, c’est vrai c’était une certaine époque entre les confs et le reste) <abbr title="Nico de 2014">N14</abbr> : c’est qu’on rêvait de faire venir Tim Berners-Lee à Paris Web en sortant des conférences. <abbr title="Nico de 2024">N24</abbr> : c’est pas facile hein ? Enfin… (ne pas lui dire qu’il va le rencontrer en 2023 et même présenter devant lui, ne pas lui dire…) <abbr title="Nico de 2014">N14</abbr> : et au moins les réseaux sociaux donnent une saine émulation. Pourquoi tu t’étouffes ? <abbr title="Nico de 2024">N24</abbr> : disons que les réseaux sociaux… évolueront étrangement à l’avenir. (comment lui expliquer qu’il va en fuir certains pour des raisons de santé mentale ?)
<abbr title="Nico de 2014">N14</abbr> : en bien ou en mal ? C’est que <a href="https://www.nicolas-hoffmann.net/source/1663-J-adore-Twitter.html">j’aime bien Twitter</a> moi. <abbr title="Nico de 2024">N24</abbr> : joker. (en mal !) <abbr title="Nico de 2014">N14</abbr> : rassure-moi, les gens sont toujours là au moins ? <abbr title="Nico de 2024">N24</abbr> : majoritairement oui. Ça évoluera. (j’ai la sensation qu’on n’a jamais été aussi seuls mais bon…)
<abbr title="Nico de 2004">N04</abbr> : (sort des vapes) <abbr title="Nico de 2014">N14</abbr> : tiens, respire un bon coup gamin. Tu as tourné de l’œil, c’est pas grave. <abbr title="Nico de 2024">N24</abbr> : ça va vieux ? Enfin jeune. <abbr title="Nico de 2004">N04</abbr> : ça va. Là, j’avoue que je suis dépassé. <abbr title="Nico de 2014">N14</abbr> et <abbr title="Nico de 2024">N24</abbr> : oui, ça autant t’y habituer… <abbr title="Nico de 2004">N04</abbr> et <abbr title="Nico de 2014">N14</abbr> : ça fait peur des fois ce sentiment.
Les trois se regardent avec un sourire. <abbr title="Nico de 2024">N24</abbr> : oui, ne vous inquiétez pas pour ça. Apprenez, vivez, faites ce qui vous semble juste, fussé-ce <a href="https://www.nicolas-hoffmann.net/source/1704-Je-hacke-le-retour-d-experience-via-un-phrase-veloute-Sud-Web.html">être de la poésie</a> ou <a href="https://www.nicolas-hoffmann.net/source/43-Argh-Montjoie.html">bloguer sur des choses insignifiantes mais si importantes</a>. Le temps est sans importance, seule la vie est importante.
Note du Nico de 2024 : même si le blog est très calme depuis plusieurs années, la-vie-toussa, 20 ans de blog, ce n’est pas rien. Un espace de liberté, intemporel, délicieusement imparfait, rouillé mais aussi durable… chapeau les gars. Je pensais revenir dans le passé en conquérant blagueur, et c’est vous qui me redonnez cette flamme : le gamin m’a rappelé cette passion, et l’autre me rappelle tout le chemin parcouru. Même si j’ai appris une certaine sagesse, finalement… vous z’êtes pas mal les gamins.
Nico de 2034, passe une tête par la fenêtre : dites les gars, j’ose vous parler de la suite ? Les Nico de 2004 à 2024 : OH LE CON !!!
On remet ça dans 10 ans, peut-être. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1719-Vous-souvenez-vous-du-futur-deuxieme.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1719-Vous-souvenez-vous-du-futur-deuxieme.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Wed, 24 Apr 2024 22:09:16 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Putain 20 ans ! ]]></title>
<description><![CDATA[ Hé oui, <a href="https://www.nicolas-hoffmann.net/source/2-ENFIN-j-y-suis-arrive.html">ce site a 20 ans</a>… et deux jours.
En attendant, si vous avez envie d’envoyer un pied de nez aux gens qui vous disent que <abbr title="PHP Hypertext Preprocessor" xml:lang="en" lang="en">PHP</abbr> ou autres <abbr title="Cascading Style Sheet" xml:lang="en" lang="en">CSS</abbr> sont morts et qu’il faut forcément passer par une plateforme ou je-ne-sais-quelle-techno qui lave plus blanc que blanc… hé bien, ça tient encore la route pour de l’ancien.
Une petite surprise est en préparation, je suis en train de la finaliser. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1718-Putain-20-ans.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1718-Putain-20-ans.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Mon, 22 Apr 2024 10:50:05 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Note de lecture : La Légion Zodiaque, Légendes d’Illuminaria ]]></title>
<description><![CDATA[ J’ai eu le plaisir de recevoir le livre de David « Deltakosh » Catuhe, intitulé « La Légion Zodiaque, Légendes d’Illuminaria ».<div><img src="https://www.nicolas-hoffmann.net/images/divers/legion-zodiaque" width="200" height="250" alt="La Légion Zodiaque, Légendes d’Illuminaria" /></div>Que dire ?
J’avoue que le travail de David sur les chevaliers a attiré ma curiosité, revisiter les mythiques chevaliers d’or n’est pas un pari facile : il touche à des icônes, n’importe quel fan a forcément son chevalier préféré, ou plusieurs (Kanon et Shaka pour ma part, même si j’aime bien Aldébaran et Manigoldo/El Cid).
En fait, cela va plus loin. En lisant ce livre, on se rend compte que l’auteur a imaginé un monde plus grand, différent. On n’en voit actuellement que quelques bribes, mais il y a un petit quelque chose qui fait… qu’on a envie d’en savoir plus, probablement la narration indirecte. (et une certaine passion personnelle pour la mythologie grecque)
En tout cas, le livre est de très belle facture : les illustrations sont magnifiques, les textes sont courts mais soignés, l’objet ne dépareillera pas dans une belle bibliothèque.
En conclusion, je reviens sur ma précédente phrase : on a envie d’en savoir plus, mais genre vraiment plus. 
Petit message personnel : David, si tu as besoin d’un relecteur de type grammar-nazi ou d’un autre acolyte pour explorer Illuminaria… je suis ton homme. ;)
Pour en savoir plus, <a href="https://www.amazon.fr/Légion-Zodiaque-David-Catuhe/dp/B0BX8WR2NV/ref=sr_1_3?__mk_fr_FR=ÅMÅŽÕÑ">La Légion Zodiaque, Légendes d’Illuminaria, sur Amazon</a> ou <a href="https://www.deltakosh.com/tales-of-illuminaria" hreflang="en">sur le site de David</a>.
Addendum : si par hasard, vous aimez le podcast de la Confrérie, peut-être avez-vous entendu les (més)aventures de la création de ce livre, où l’auteur — non sans un certain humour — relate les obstacles de la genèse de cet ouvrage : <a href="https://www.deltakosh.com/laconfrerie-podcast/episode/31d4c207/la-creation-de-livres-et-le-monde-des-figurines-de-bourges">la confrérie, la création de livre</a>.
D’autres épisode relatent des histoires toutes plus amusantes les unes que les autres avec le livre en toile de fond, comme <a href="https://www.deltakosh.com/laconfrerie-podcast/episode/31d6e40c/plongee-dans-un-forum-18-25-et-le-top-3-de-nos-jeux-les-plus-marquants">Plongée dans un forum 18-25 et le top 3 de nos jeux les plus marquants</a>.
Je n’écoute que très peu de podcasts, mais j’avoue que celui-ci m’accompagne souvent, je suis en train de les rattraper à reculons. Bon boulot les gars ! ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1717-Note-de-lecture-La-Legion-Zodiaque-Legendes-d-Illuminaria.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1717-Note-de-lecture-La-Legion-Zodiaque-Legendes-d-Illuminaria.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Mon, 24 Jul 2023 14:59:22 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Focus-visible, la pseudo-classe qui met presque tout le monde d’accord ]]></title>
<description><![CDATA[ Toute belle histoire commence par…
<h3>Il était une fois</h3>
Il y a bien longtemps (pas tant que ça mais bon), à chaque fois que vous cliquiez sur un bouton, vous pouviez entendre un ou une <abbr title="Product Owner" lang="en" xml:lang="en">PO</abbr>/utilisateur/designer/dev/autre dire :
<ul><li>« Oh, cette vilaine bordure bleue ou noire est-ce qu’on pourrait l’enlever ? »</li><li>Mais c’est nécessaire pour les utilisateurs de clavier !</li><li>Oui mais c’est moche, on peut l’enlever ? À propos, je n’utilise pas mon clavier.</li><li>(ton qui monte) C’est nécessaire pour les utilisateurs de clavier !!!</li><li>Oui mais c’est laid, on peut l’enlever ? À propos, je n’utilise pas mon clavier.</li><li>Etc.</li></ul>
La cause principale de ces discussions interminables était la suivante : cliquer sur un élément active les styles de focus, comme avec le clavier.
Il était impossible de différencier un bouton activé via une souris ou un clavier (les deux avaient des styles de focus déclenchés), sauf avec des tonnes de JavaScript à coup sûr. En général, cela se finissait par un drame, un bon gros <code>outline: 0</code> des familles, soit la suppression complète et entière de l’indicateur visuel pour le clavier. Nigro notanda lapillo.
C’est là que <code>:focus-visible</code>, anciennement appelé <code>:focus-ring</code> (l’idée n’est vraiment pas récente), entre en jeu pour sauver nos âmes.<div class="centre"><img src="https://www.nicolas-hoffmann.net/images/divers/focusing.png" width="391" height="70" alt="Emoji focusing sur Slack, on parle de focus, donc c’est une blague absolument lamentable mais j’aime." /></div><h3>Le besoin</h3>
L’un des besoins les plus élémentaires lors de l’utilisation d’un clavier est de pouvoir savoir où vous vous trouvez dans l’interface.
S’il n’y a pas de surbrillance visible de l’élément actuel, l’utilisateur peut se perdre, la navigation devient vraiment pénible et une opération simple comme atteindre un lien nécessite soudainement une attention folle… ou n’est tout simplement pas possible.
Dans le langage expert de l’accessibilité, si je ne me trompe pas, dans les <abbr title="Web Content Accessibility Guidelines" lang="en" xml:lang="en">WCAG</abbr>, c’est le <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible" lang="en" xml:lang="en" hreflang="en">Success Criterion 2.4.7 Focus Visible</a>: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible (traduction approximative : toute interface utilisable au clavier a un mode d’utilisation où le focus clavier est visible).
<h3>En pratique</h3>
Avant, on doublait les styles entre <code>:focus</code> et <code>:hover</code>, et on priait pour que ça passe côté produit sans prendre de remarque comme au début de cet article.
Là, on peut se permettre de totalement virer l’<code>outline</code> au <code>:hover</code>, et de bien renforcer ce dernier avec <code>:focus-visible</code>.
Quelque chose comme :
<pre><code>.mon-button:focus { outline: none; } .mon-button:focus-visible { outline: 3px solid chartreuse; // je ne peux être tenu responsable du choix de cette couleur. } </code></pre>
<h3>Comment <code>:focus-visible</code> marche</h3>
Même si l’on pourrait croire que c’est de la magie… il n’y a aucune magie là dedans. Grosso modo, le navigateur utilise certaines heuristiques pour déterminer si – selon lui – l’utilisation doit déclencher <code>:focus-visible</code> ou non.
<abbr title="Too Long Didn’t Read" lang="en" xml:lang="en">TLDR</abbr> : si l’utilisateur utilise le clavier.
En réalité, c’est un peu plus complexe : je vous conseille de lire la <a href="https://www.w3.org/TR/selectors-4/#the-focus-visible-pseudo" lang="en" xml:lang="en" hreflang="en">spécification de <code>:focus-visible</code></a>.
Je ne vais pas tout détailler, d’autres l’ont bien fait comme <a href="https://css-tricks.com/almanac/selectors/f/focus-visible/#aa-how-do-browsers-determine-when-something-is-focus-visible" lang="en" xml:lang="en" hreflang="en">How do browsers determine when something is :focus-visible?</a>, mais je m’arrête sur un exemple, les formulaires.
On pourrait se dire assez légitimement « si je clique sur un champ de formulaire, <code>:focus-visible</code> ne sera pas activé ». Sauf que non ! Si un élément – comme un champ de formulaire – a besoin du clavier pour fonctionner, il activera <code>:focus-visible</code>, qu’on clique dessus ou qu’on l’atteigne au clavier.
En pratique, cela se gère très facilement.
C’est pour cela que je vous invite à lire la spécification et à tester. D’expérience, j’ai vu quelques cas qui ont du sens une fois la spécification lue, mais qui peuvent surprendre (si une modale apparait subitement au lancement du site avant que l’utilisateur n’ait pu interagir, etc.).
<h3>La compatibilité</h3>
Le support est excellent sur les navigateurs récents : <a href="https://caniuse.com/css-focus-visible" hreflang="en"><code>:focus-visible</code> sur Can I Use</a>. Le souci est comme d’habitude <abbr title="Internet Explorer" lang="en" xml:lang="en">IE</abbr>11 (mais on s’en fout) et quelques vieux Safari, à vous de voir si vous vous en foutez ou non.
Là où c’est gênant avec ces Safari, c’est que comme ils ne reconnaissent pas du tout <code>:focus-visible</code>, ils décident de purement ignorer la ligne… et parfois d’autres lignes factorisées avec. Ce qui amène à <a href="https://github.com/ProtonMail/WebClients/blob/main/applications/mail/src/app/styles/_layout.scss#L35">des commentaires amusants</a>.
Au pire, vous avez un outil magique pour déployer en douceur : <code>@supports selector(:focus-visible) {</code>. En clair, si <code>:focus-visible</code> est supporté, alors… faire quelque chose.
Il a pu m’arriver de le déployer en douce, et – constatant que personne n’avait rien trouvé à redire en 6 mois – d'annoncer fièrement que c’était en production depuis une demi-année sans que personne ne s’en soit jamais plaint.
<h3>Pour conclure</h3>
Cette pseudo-classe est un régal à utiliser, et elle permet enfin de concilier demandes de designs et accessibilité, voir de même séparer totalement l’expérience clavier du reste. Albo notanda lapillo. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1716-Focus-visible-la-pseudo-classe-qui-met-presque-tout-le-monde-d-accord.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1716-Focus-visible-la-pseudo-classe-qui-met-presque-tout-le-monde-d-accord.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Mon, 05 Dec 2022 14:52:19 +0100</pubDate>
</item>
<item>
<title><![CDATA[ Ces modifications simples (custom scroll via CSS) ]]></title>
<description><![CDATA[ Dans la suite directe du billet expliquant qu’<a href="https://www.nicolas-hoffmann.net/source/1714-des-metriques-pour-suivre-activite-dev.html">estimer est difficile/impossible</a>, 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 <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr>. Le tout est fait à coups de <a href="https://developer.mozilla.org/fr/docs/Web/CSS/scrollbar-width"><code>scrollbar-width</code></a>, <a href="https://developer.mozilla.org/fr/docs/Web/CSS/scrollbar-color"><code>scrollbar-color</code></a> pour les navigateurs le supportant, et à coups de <a href="https://developer.mozilla.org/fr/docs/Web/CSS/::-webkit-scrollbar"><code>::-webkit-scrollbar</code></a> 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 :
<ol><li>créer une variable pour l’activer ou non ;</li><li>la mettre dans le fragment Sass.</li></ol>
Ok, pas de souci, c’est vraiment facile à faire, je prévois de faire ça en une petite heure.<div><img src="https://www.nicolas-hoffmann.net/images/divers/wcgw.jpg" width="300" height="223" alt="Que pourrait-il mal se passer ?" loading="lazy" /></div>Effectivement, je fais ces modifications très rapidement… et je teste vite fait. Pas de souci, ça s’active bien par exemple sur <a href="https://design-system.protontech.ch/" hreflang="en">la page d’accueil du Design System de ProtonMail</a>. 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 : <a href="https://design-system.protontech.ch/conversations/" hreflang="en">mockup des conversations de ProtonMail v4</a> (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).<div><img src="https://www.nicolas-hoffmann.net/images/divers/bug-scroll.png" width="374" height="390" alt="Un bug du Custom Scroll" loading="lazy" /></div>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 ?
<ul><li>Essayer de trifouiller la transparence du scroll ? Pas possible.</li><li>Essayer de mettre le scroll par-dessus ? Soyons sérieux, pas possible.</li><li>Mettre une bordure sur chaque élément ! Non. Sinon le conteneur n’aura pas la bordure jusqu’en bas si pas assez de messages.</li></ul>
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 ? ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1715-Ces-modifications-simples-custom-scroll-via-CSS.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1715-Ces-modifications-simples-custom-scroll-via-CSS.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Thu, 02 Jul 2020 15:32:11 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Des métriques pour suivre l’activité d’un dev ? ]]></title>
<description><![CDATA[ Il y a quelques mois, j’ai suggéré sur Twitter l’idée de faire <a href="https://twitter.com/Nico3333fr/status/1194560070497001472">un billet pour dénoncer les fausses-bonnes idées en matière de métriques</a> 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.<div><img src="https://www.nicolas-hoffmann.net/images/divers/notre-projet.webp" width="480" height="270" alt="Les mauvaises métriques, parce que c’est NOTRE PROJET" loading="lazy" /></div><h3>Idée débile numéro 1 : au poids !</h3>
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 <abbr title="Pull Request" lang="en" xml:lang="en">PR</abbr> qui fait passer ProtonMail de sa v3 à la v4 en cours de conception, nous avons réussi quelque chose d’extraordinaire.<div><img src="https://www.nicolas-hoffmann.net/images/divers/v3-v4.png" width="159" height="31" alt="v3 à v4, 50000 ajouts et 3 fois plus de suppressions" loading="lazy" /></div>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.
<h3>Idée débile numéro 2 : au commit !</h3>
Regardons le contribution graph de <a href="https://github.com/ProtonMail/react-components/" lang="en" xml:lang="en" hreflang="en">react-components</a>, 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)<div><a href="https://www.nicolas-hoffmann.net/images/divers/contribution-graph-1.png" title="Contribution Graph version 1… (nouvelle fenêtre)" target="_blank" class="internal"><img src="https://www.nicolas-hoffmann.net/images/divers/contribution-graph-1.png" width="300" height="296" alt="Contribution Graph version 1…" loading="lazy" /></a></div>Je suis 3e, moi, le spécialiste <abbr title="Cascading Style Sheet" xml:lang="en" lang="en">CSS</abbr> de la boite !! Seuls deux devs me dépassent au nombre de commits, et je suis devant 5 autres devs <abbr title="JavaScript" xml:lang="en" lang="en">JS</abbr>. 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 <a href="https://github.com/ProtonMail/react-components/graphs/contributors">à la source</a>.<div><a href="https://www.nicolas-hoffmann.net/images/divers/contribution-graph-2.png" title="Contribution Graph, la vraie version, nous sachons (nouvelle fenêtre)" target="_blank" class="internal"><img src="https://www.nicolas-hoffmann.net/images/divers/contribution-graph-2.png" width="300" height="297" alt="Contribution Graph, la vraie version, nous sachons" loading="lazy" /></a></div>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 :
<ul><li>Les 4e, 5e et 6e modifient bien plus de choses que moi et c’est normal, c’est leur job de faire du JavaScript !</li><li>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.</li></ul>
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. 
<h3>Idée débile numéro 3 : au temps !</h3>
Si on regarde bêtement le changement dans la <abbr title="Pull Request" lang="en" xml:lang="en">PR</abbr> : « Punaise, il lui a fallu 4H pour changer deux classes dans les templates de l’app ? Il fait quoi le dev <abbr title="User Interface" lang="en" xml:lang="en">UI</abbr>, il se fait bronzer les doigts de pied ? »
C’est possible que le dev <abbr title="User Interface" lang="en" xml:lang="en">UI</abbr> se fasse bronzer oui. Mais ce qui est possible aussi : 
<ul><li>c’est qu’il ait galéré à trouver le maillon qui foire dans un projet complexe avec des abstractions de malade ;</li><li>qu’il ait été dérangé entre temps ou demandé sur d’autres trucs ;</li><li>que le souci ait été particulièrement dur à reproduire ;</li><li>ou que la sacro-sainte solution soit éclatée sur 4 projets avec 20 contextes, la rendant particulièrement délicate ;</li><li>ou qu’il soit parti sur une autre piste, et qu’après 20 tentatives, 2 crises de nerfs, 4 arbitrages, un <code>npm i</code> 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é).</li></ul>
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.
<h3>De meilleures métriques</h3>
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 : 
<ul><li>De la valeur business est-elle produite dans le temps sur un même produit (je cite <a href="https://twitter.com/alborq42/status/1194624076633067520">une réponse très juste</a>) ?</li><li>Les clients sont-ils contents ?</li><li>Est-ce que votre dev est apprécié des autres humainement ?</li><li>Est-ce que son travail facilite celui des autres ?</li><li>Maîtrise-t-il sa partie ?</li><li>Est-ce que les tâches sont expédiées et résolues ?</li><li>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 ?</li><li>Est-ce que sa partie facilite des évolutions non prévues initialement ?</li><li>Etc.</li></ul>
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. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1714-des-metriques-pour-suivre-activite-dev.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1714-des-metriques-pour-suivre-activite-dev.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Mon, 11 May 2020 19:06:06 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Note de lecture : Grid Layout, de Raphaël Goetter ]]></title>
<description><![CDATA[ J’ai eu le plaisir de recevoir le dernier livre de Raphaël Goetter, intitulé « Grid Layout, vous allez enfin aimer <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> ». Ce livre est sorti depuis le 18 Février de cette année.<div><img src="https://www.nicolas-hoffmann.net/images/divers/grid-couverture-mini.png" width="165" height="200" alt="Grid Layout, par Raphaël Goetter" /></div>Un livre entier pour un seul module de <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> ! Est-ce bien raisonnable ?
Hé bien, autant dire de suite : oui, et cela ne sera pas de trop ! Si le positionnement en <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> 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 <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> (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 <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> et des <a href="https://knacss.com/">Knacss</a>, 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 <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> 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, <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr>, 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 <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr>. ;)
Si vous voulez en savoir plus sur cet ouvrage, voici le site dédié : <a href="http://goetter.fr/livres/gridlayout/">Grid Layout, vous allez enfin aimer <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr></a>. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1713-Note-de-lecture-Grid-Layout-de-Raphael-Goetter.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1713-Note-de-lecture-Grid-Layout-de-Raphael-Goetter.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Tue, 30 Apr 2019 14:59:00 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Créer un RevealJS light avec CSS Scroll Snap Points ]]></title>
<description><![CDATA[ Cela faisait un certain moment que je voulais tester ce module <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> ainsi d’autres choses, l’occasion m’en a été donnée avec <a href="https://www.nicolas-hoffmann.net/sudweb/">mes slides de Sud Web 2018</a>. 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.<div class="centre"><img src="https://www.nicolas-hoffmann.net/images/divers/15ans-sudweb.png" width="300" height="160" alt="Présentation à Sud Web" /></div><h3 lang="en" xml:lang="en"><abbr title="Cascading Style Sheet">CSS</abbr> Scroll Snap Points</h3>
L’idée de <abbr title="Cascading Style Sheet">CSS</abbr> 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) <a href="https://codepen.io/nico3333fr/pen/BVLeKY">un exemple</a>.
Comme vous pouvez le voir, l’idée des slides en <abbr title="HyperText Markup Language" lang="en" xml:lang="en">HTML</abbr> est assez simple. En clair, chaque élément aura une taille de <code>100%</code> et une hauteur de <code>100vh</code>. Et dès qu’on se déplacera, <abbr title="Cascading Style Sheet">CSS</abbr> 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 <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> 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 <code>scroll-snap-type: mandatory</code> et <code>scroll-snap-points-x: repeat(100%)</code>. Et à donner à chaque slide la largeur/hauteur complète du viewport. Oui, c’est aussi simple que cela.
La doc : <a href="https://developer.mozilla.org/fr/docs/Web/CSS/scroll-snap-type"><abbr title="Cascading Style Sheet">CSS</abbr> Scroll Snap Points</a>
<h3 lang="en" xml:lang="en">Intersection Observer</h3>
Grosso modo, l’idée de cette <abbr title="Application Programming Interface" lang="en" xml:lang="en">API</abbr> 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 <a href="https://developer.mozilla.org/fr/docs/Web/API/Intersection_Observer_API">la documentation d’Intersection Observer</a>.
L’idée était de pouvoir ajouter une classe pour savoir quelle était la slide active. En clair, je surveille toutes les slides. 
<pre><code>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'); } </code></pre>
Et quand une passe dans le viewport, je lui ajoute la classe <code>is-active</code> et au passage j’ajoute le fragment correspondant dans l’URL.
<pre><code>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'); } }); } </code></pre>
C’était un caprice au début, mais cela va se révéler utile ensuite.
<h3>Ajouter des contenus qui apparaissent/bougent</h3>
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.
<pre><code><button class="js-next" data-next="next_2">Ce qui change…</button></code></pre>
En clair, quand ce bouton est activé, il va chopper l’élément qui a l’<code>id</code> <code>next_2</code> et il le fait apparaître.
Oui c’est pas génial point de vue accessibilité, on peut faire mieux, je sais ! :)
<h3>Gérer la télécommande</h3>
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 <a href="http://keycode.info/">keycode.info</a>), comme si on appuyait sur <kbd>Page Down</kbd> (34) ou <kbd>Page Up</kbd> (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é <code>scrollIntoView</code>, et comme je n’avais pas de souci de compatibilité, j’ai utilisé l’option <code>behavior: "smooth"</code> (attention, <a href="https://developer.mozilla.org/fr/docs/Web/API/Element/scrollIntoView">le support est très variable selon les navigateurs</a>, la version de base ne marche pas trop mal, mais <code>scrollIntoViewOptions</code> 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.
<pre><code>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'); } } }</code></pre>
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.
<h3>En conclusion</h3>
Certes c’est un exercice de style fait à la rache, mais grosso modo, avec quelques <abbr title="Application Programming Interface" lang="en" xml:lang="en">API</abbr>s, de la <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr>, 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 à <abbr title="Cascading Style Sheet">CSS</abbr> Scroll Snap Points… quand il fonctionnera correctement chez Webkit.
Voilà, si vous avez des remarques ou des commentaires, à votre disposition ! ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1712-Creer-un-RevealJS-light-avec-CSS-Scroll-Snap-Points.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1712-Creer-un-RevealJS-light-avec-CSS-Scroll-Snap-Points.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Thu, 07 Jun 2018 17:49:44 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Le manifeste du développeur à moyen ou long terme ]]></title>
<description><![CDATA[ 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. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1711-Le-manifeste-du-developpeur-a-moyen-ou-long-terme.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1711-Le-manifeste-du-developpeur-a-moyen-ou-long-terme.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Tue, 01 May 2018 10:24:57 +0200</pubDate>
</item>
<item>
<title><![CDATA[ Déployer cache-control: immutable avec du cache-busting ]]></title>
<description><![CDATA[ L’autre jour, je m’amusais à tester mon site <a href="https://van11y.net/fr/">Van11y</a> sur divers outils, et notamment celui-ci : <a href="https://sonarwhal.com/scanner/" hreflang="en" xml:lang="en" lang="en">Sonarwhal</a>.
Ce dernier propose une piste d’amélioration que je n’avais pas essayée jusqu’à présent, à savoir implémenter <code>Cache-Control: immutable</code>. J’avais entendu parler de cette possibilité via ma veille habituelle, mais je n’avais jamais essayé en pratique.<div class="centre"><img src="https://www.nicolas-hoffmann.net/images/divers/cache-control-immutable.png" width="335" height="105" alt="cache-control: immutable" /></div><h3>Cache-control: immutable</h3>
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 <kbd>F5</kbd> (<abbr title="Y a du neuf sur ma page ?????">allez savoir pourquoi</abbr> !). 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 : 
<blockquote>La requête la plus rapide est celle que l’on ne fait jamais.</blockquote>
Bref, l’intérêt de <code>Cache-Control: immutable</code> ? 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.
<h3>Avoir une stratégie de cache-busting</h3>
J’en avais une sur les <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> 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 <abbr title="Content Management System" lang="en" xml:lang="en">CMS</abbr> et bon nombre d’autres systèmes le font pour vous automatiquement.
En pratique, sans cette stratégie, si vous envoyez le fichier <code>/images/logo.svg</code>, 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’<abbr title="Uniform Resource Locator" xml:lang="en" lang="en">URL</abbr>-rewriting (la réécriture d’adresse en bon français). En clair, on va demander au serveur de réécrire l’adresse <code>/images/logo_<ici une valeur qu’on fera changer>.svg</code> en <code>/images/logo.svg</code>. Cela peut se faire via un <code>htaccess</code> :
<pre><code>RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.+)_(\d+)\.(css|js)$ $1.$3 [L]</code></pre>
En clair, si l’<abbr title="Uniform Resource Locator" xml:lang="en" lang="en">URL</abbr> demandée n’est ni un fichier ni un répertoire, et avec les extensions ci-dessus, alors <code>fichier_xxxxxxxx.extension</code> va être réécrit ainsi sur le serveur <code>fichier.extension</code>. Par exemple, <code>css/styles_mini_1516114378.css</code> sera réécrit en <code>css/styles_mini.css</code> (et ce fichier est bien sur mon serveur).
Par contre, c’est bien l’<abbr title="Uniform Resource Locator" xml:lang="en" lang="en">URL</abbr> <code>css/styles_mini_1516114378.css</code> qui va être mise en cache. Une mise à jour sur la <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> ? Le cache-buster va être mis à jour, par exemple en <code>css/styles_mini_1516114666.css</code>. 
<h3>En pratique pour le cache-busting</h3>
Grosso modo, j’ai repéré tous les types de fichiers qui devaient en bénéficier, et j’ai mis cela dans mon <code>htaccess</code> principal :
<pre><code>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]</code></pre>
Ensuite, il a fallu ajouter le cache-buster partout où il est nécessaire. Sur les <code>img</code> de contenu, j’ai utilisé une fonction en <abbr title="PHP Hypertext Preprocessor" xml:lang="en" lang="en">PHP</abbr> qui renvoie le timestamp Unix de dernière modification du fichier (<a href="http://php.net/manual/fr/function.filemtime.php">filemtime()</a>) et qui insère le cache-buster dans le nom du fichier.
<pre><code>return '_'.filemtime($prefix. $chemin_img);</code></pre>
Dans la <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr>, 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 <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr>, 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 (<abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> et JavaScript). Hop, tout est automatisé, point d’effort. 
<h3>En pratique pour déployer l’en-tête proprement dite</h3>
Une fois la stratégie de cache-busting correctement déployée, il ne reste plus grand chose à faire, j’ai mis ceci dans <a href="https://github.com/nico3333fr/htaccess-useful/blob/master/.htaccess" hreflang="en">mon <code>htaccess</code> habituel</a> :
<pre><code><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> </code></pre>
Et c’est terminé.
Un point de détail amusant : Sonarwhal va – à juste titre – vous gronder si vous déployez <code>Cache-Control: immutable</code> sans stratégie de cache-busting. L’outil ne reconnaissait pas celle que j’avais utilisée, <a href="https://github.com/sonarwhal/sonarwhal/issues/741#issuecomment-358002292" hreflang="en">je le signale aux développeurs</a>, qui ont été super réactifs et qui ont mis l’outil à jour. Un bravo à eux !
Un autre point de détail : <code>Cache-Control: immutable</code> ne sera honoré sous Firefox que si le contenu est servi en <abbr title="HyperText Transfer Protocol Secure" lang="en" xml:lang="en">HTTPS</abbr>. Cela semble assez logique : il faut être sûr que le contenu n’ait pas été modifié entre le serveur et le navigateur.
<h3>En conclusion</h3>
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 <code>Cache-Control: immutable</code>.
Pour en savoir plus :
<ul><li><a href="https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/" hreflang="en" xml:lang="en" lang="en">Using Immutable Caching To Speed Up The Web</a></li><li><a href="https://discuss.httparchive.org/t/cache-control-immutable-a-year-later/1195" hreflang="en" xml:lang="en" lang="en">Cache Control Immutable - A Year Later</a></li></ul> ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1710-Deployer-cache-control-immutable-avec-du-cache-busting.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1710-Deployer-cache-control-immutable-avec-du-cache-busting.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Thu, 08 Feb 2018 18:13:57 +0100</pubDate>
</item>
<item>
<title><![CDATA[ J’ai arrêté de troller, retour d’expérience ]]></title>
<description><![CDATA[ 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.
<h3>L’existant</h3>
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, <abbr lang="en" xml:lang="en" title="Cascading Style Sheet">CSS</abbr> 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).
<h3>Protocole de désintoxication</h3>
Un sevrage brutal est trop difficile pour commencer. Il faut soit trouver un substitut (<a href="https://www.nicolas-hoffmann.net/source/1708-Un-commit-tous-les-jours.html">un commit tous les jours</a> 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.
<h3>En pratique</h3>
Perso, j’ai trouvé un réflexe. Avant de réagir à un sujet potentiellement polémique, je me pose les questions suivantes :
<ul><li>Cela va mener à quoi ? Si c’est à rien, autant se taire. (refaire Boostrap en Dart… Thomas, si tu me lis, je t’aime)</li><li>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).</li><li>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).</li><li>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.</li></ul>
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 ».
<h3>Ce que les trolls disent de nous</h3>
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 <a href="https://twitter.com/Nico3333fr/status/943943315862454272">m’auto-citer</a> :
<blockquote>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.</blockquote>
(vous n’imaginez pas le travail sur soi pour dire cela, je me suis senti grand l’espace d’un tweet)
<h3>Les résultats</h3>
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.
<h3>Troller bio et pas industriel</h3>
Curieusement, dans mon imaginaire, troller est lié à l’humour. Même si je ne fréquente plus tant certains très bons sites comme <a href="http://linuxfr.org/">LinuxFr</a>, 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 <abbr title="Very Important Prout" lang="en" xml:lang="en">VIP</abbr>… 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 (<a href="https://www.dictionnaire.exionnaire.com/que-signifie.php?mot=-ine">le suffixe -ine est un diminutif</a>, et on va encore dire que le changement de genre lors du passage au diminutif n’est pas une bonne chose). Sans blague. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1709-J-ai-arrete-de-troller-retour-d-experience.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1709-J-ai-arrete-de-troller-retour-d-experience.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Sat, 30 Dec 2017 18:54:34 +0100</pubDate>
</item>
<item>
<title><![CDATA[ Un commit tous les jours ]]></title>
<description><![CDATA[ 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). <div class="centre"><img src="https://www.nicolas-hoffmann.net/images/divers/sdb-github.jpg" width="400" height="271" alt="Ma salle de bain, seuls les vrais sauront" /></div>Voici un retour d’expérience.
<h3>Un constat</h3>
Grosso modo, en 2016, j’avais fait <a href="https://github.com/nico3333fr?tab=overview&from=2016-01-01&to=2016-12-31&utf8=%E2%9C%93" hreflang="en">511 contributions sur Github</a>. 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ââââ…
<h3>L’idée proprement dite</h3>
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 <a href="https://github.com/nico3333fr/CSP-useful" hreflang="en"><abbr title="Content Security Policy" lang="en" xml:lang="en">CSP</abbr></a>, <a href="https://rocssti.net/">Röcssti</a>, <a href="https://van11y.net/fr/">Van11y</a>, <a href="https://a11y.nicolas-hoffmann.net/" hreflang="en">les plugins accessibles avec jQuery</a> 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.
<h3>En pratique</h3>
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 <abbr title="Content Security Policy" lang="en" xml:lang="en">CSP</abbr> 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.
<h3>Retour d’expérience</h3>
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 <a href="https://github.com/nico3333fr" hreflang="en">contribution graph</a> n’est pas définitif, mais il est plutôt intéressant.<div class="centre"><img src="https://www.nicolas-hoffmann.net/images/divers/contribution-graph-nico-2017.png" width="600" height="172" alt="Contribution graph de Nico pour 2017 (y a beaucoup de vert)" /></div>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 <abbr title="Content Security Policy" lang="en" xml:lang="en">CSP</abbr>.
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 <a href="https://van11y.net/fr/">Van11y</a> a été codé ainsi, à l’aller pour Aix en Provence (coucou Sud Web).
<h3>Conclusion</h3>
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. ]]>
</description>
<guid>https://www.nicolas-hoffmann.net/source/1708-Un-commit-tous-les-jours.html</guid>
<link>https://www.nicolas-hoffmann.net/source/1708-Un-commit-tous-les-jours.html</link>
<author>contact@nicolas-hoffmann.net (Nico)</author>
<pubDate>Fri, 17 Nov 2017 14:43:29 +0100</pubDate>
</item>
</channel>
</rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=http%3A//www.nicolas-hoffmann.net/rss/index.php"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//www.nicolas-hoffmann.net/rss/index.php

Home · About · News · Docs · Terms