Je viens de faire une mise à jour assez importante sur le moteur de blog qui fait tourner mon site.
Si jamais vous voyez des problèmes (surtout des liens brisés), n’hésitez pas à me le signaler.

<minute=geek>

Concernant la mise à jour en elle même, au niveau du code, je viens de virer ce que je pense être l’une des plus anciennes fonctions PHP du site. Ça ne vous dit peut-être rien, mais en ce qui me concerne, ça m’amuse :).

Le code c’est comme un organisme : chaque fonction, chaque ligne est une cellule. Parfois, les cellules meurent et sont remplacées. Ici c’est pareil : le code évolue et se renouvelle, sans cesse.

En l’occurrence, je viens de virer plusieurs fonctions dont la présence n’était plus pertinente.
Parfois, virer des trucs constitue une amélioration : faire le ménage permet de voir plus clair.

</minute=geek>

Un article qui explique succintement comment fonctionne un moteur de rendu d’un navigateur, en particulier comment il traite le JS, l’arbre DOM (le HTML) et le CSSOM (le CSS).

La connaissance de ceci permet de savoir où placer les différents éléments.

Par exemple : le HTML commence à charger, mais le JS est bloquant : dès qu’il y a du JS dans la page (inline, ou non), alors le parsage du HTML se pause : ceci, car le JS peut modifier le HTML. Il est donc inutile de parser un truc qui peut être changé par la suite.

Or, le JS peut également toucher au CSS. Pour ça, le CSSOM doit être prêt. Donc le CSS doit être parsé pour que le JS puisse être éxécuté, et le JS doit être exécuté si on peut que le HTML soit parsé.

Dit autrement, le navigateur doit avoir fini de charger dans cet ordre :
– le CSS
– le JS (se finit après le JS)
– le HTML (terminé à la fin, quand la dernière balise se ferme)

Aussi, si on veut que la page s’affiche vite pour que le lecteur le lise rapidement, il faut donc que le CSS soit fini le plus tôt possible pour que l’information (portée par le HTML) soit affichée correctement.
Enfin, vu que le JS est bloquant, l’information utile de la page doit être affichée avant l’exécution des scripts.

Du coup, on voit bien que le CSS doit être placé au début du document et le JS à la fin : https://lehollandaisvolant.net/?d=2015/08/27/18/46/54-pourquoi-mettre-le-javascript-a-la-fin-et-le-css-au-debut

Petite mise à niveau de cette page avec mes récentes découvertes (async, defer, json…).
Bref, un tas de bonnes pratiques pour les performances (mais aussi un brin d’accessibilité).

**

Il faut aussi noter que les outils comme GTMetrix font des analyses instantanées d’une page : ils ne regardent pas le contexte global dans lequel une page est vue par le navigateur.

En ce qui me concerne, je préfère avoir une seule image d’illustration : que l’article soit dans un petit bloc ou dans un gros bloc, l’image est unique. Et si le visiteur visite deux pages à la suite, il n’aura à télécharger le fichier qu’une seule fois.
C’est le cas par exemple pour les images d’illustration des articles sur le blog.

Bien souvent, en revanche, GTMetrix me dit de spécifier des images à la bonne taille pour chaque affichage : donc une petite et une grande. Si l’utilisateur affiche les deux pages à la suite (très courant pour mon site), alors il devra télécharger plusieurs images… Ce n’est donc pas optimal.

Il faut donc appliquer tout ça de façon pragmatique et réfléchie, pas appliquer bêtement juste pour avoir un bon score à tout prix (justement par ce que ce score ne reflète pas une navigation réelle).

Même chose pour l’aliasing sur les images : parfois un gros PNG en 1000x1000 sera bien plus léger qu’un PNG mis à l’échelle en 500x500.
Or, GTMetrix dira que votre image est trop grande et devra être réduire de moitié. Il dira même que votre image sera 50% plus légère, ce qui est faux.

Exemple :
https://lehollandaisvolant.net/img/45/1000x1000.png (1,9 ko)
https://lehollandaisvolant.net/img/3a/500x500.png (2,5 ko)

Ceci vient du fait que PNG aime les applats de couleur unis, et que si on réduit une image, il y a un flou sur les applats, ce qui casse ce cote uni et coûte cher en taille de fichier. Ceci est un exemple bidon, mais il illustre bien le concept, et il est assez courant.

Bien vu !

L’illustration du « while » et du « do/while » avec Bip-Bip et Vil Coyote.

Oh tiens, les navigateurs ont une fonction interne pour encoder/décoder en Base64.

var encodedData = window.btoa('Hello, world'); // encode a string
var decodedData = window.atob(encodedData); // decode the string

C’est bien logique : quand on entre une URL en base64, le nav le décode, donc ils peuvent le faire.
C’est dispo dans tous les navigateurs modernes.

C’est cool, même pas besoin de lib externe si on n’en a rien à foutre d’IE :)

Pour les fichiers, c’était déjà très simple à encoder aussi : il suffisait d’utiliser readAsDataURL() sur un fichier importé avec un filereader (le contenu retourné par un input de type "file" par exemple), et c’était tout.

Bon, Timo vient de trouver comment faire des PWA, des « progressives web app ».

En gros, ce sont des pages web qui sont mis en cache sur le téléphone (ou l’ordinateur, hein). C’est donc à la limite entre la page web et l’application.

L’intérêt est multiple :
– la partie mise en cache se lance instantanément (elle est déjà sur le tél), seule est chargée la partie dynamique. Pour un blog, par exemple, les menus sont statiques et les articles sont chargés. Ça limite ainsi le transfert de données.
– la partie mise en cache est utilisable offline !
– la page est en plein écran
– c’est toujours juste du JS/HTML/CSS, donc a priori cross-browser
– c’est exécuté dans le navigateur (celui que vous voulez, du moment qu’il a un bon support des technos).

On peut imaginer un fichier HTML/CSS reprenant l’interface de votre blog, et un petit bout de JS/CSS qui récupère un flux RSS/ATOM (ou même les flux en JSON, qui sont destinés à ça). Et hop, on a une application mobile en 15 minutes.
Il y a possibilité de stoquer les données également dans un cache local.

Pour les outils web qui fonctionnent entièrement en JS (vous me voyez venir ?), il y a possibilité d’en faire assez simplement des PWA !

Je viens de commettre ça du coup : https://lehollandaisvolant.net/TEST/WEBAPPS/noteswall

C’est mon mur de notes en JS !

1) visitez la page dans votre smartphone
2) dans Firefox mobile, vous cliquez sur la petite maison dans la barre d’adresse : ça va l’ajoute au bureau, comme une app (sinon allez dans le menu > page > ajouter sur la page d’accueil)
3) c’est bon, c’est installé : online, offline : ça marche !

Pour la virer, virez juste l’icône.

Cette app en particulier est totalement offline.
Aucune requête n’est jamais faite sur mon site (sauf au moment de l’installer). Donc vos notes sont safe ^^

Oh et l’app reste parfaitement utilisable telle qu’elle dans un navigateur desktop : c’est juste une page web mise en cache, un peu plus durement que d’habitude.

Mon mur de notes est très simple et basique comme app (même pour un mur de notes). Mais les possibilités sont immenses ! J’hésitais a apprendre à faire des app android. En fait je vais apprendre mon JS et faire ça. Au moins je saurais faire des app pour toutes les plateformes en même temps

Je sens que je vais m’amuser \o/

(oui je suis un gosse qui vient de découvrir comment marcher :D)

Blague de programmeur :)

Gros +1.

Les programmes sont de plus en plus lourds sans raison apparente. C’est dingue.

L’application clavier de Google consomme constamment 150 Mo de mémoire. Est-ce qu’une application qui dessine 30 caractères sur un écran est réellement cinq fois plus complexe que Windows 95 tout entier ? L’application Google, qui est juste la recherche web empaquetée pèse 350 Mo ! Les services Google Play, que je n’utilise pas (je n’achète pas de livres, de musique, ni de film par ce biais) : 300 Mo qui sont encore pris et que je ne peux même pas libérer.

C’est pour ça que je suis fan des applications comme ça : https://simplemobiletools.github.io/ : des trucs SIMPLES.

C’est aussi pour ça que je me suis mis à faire tout ça : https://lehollandaisvolant.net/tout/tools/

À l’origine c’était pour avoir au même endroit divers outils (qrcode, base64, md5, etc.), que j’avais marre de rechercher sur Google à chaque fois que j’en avais besoin.

Au fil du temps, l’outil "QRcode" que j’utilisais est devenu une plaie avec 43856959 options esthétiques, des liens et de la pub et le champ « mettre votre texte ici » s’est perdu en même temps que le bouton « valider ».

Mes outils ne sont pas parfaits, mais ils font leur job et je m’en sers tous les jours. Pourquoi en demander plus ?

+1 pour le bonus, qui semble la solution à tous les problèmes, en ce moment -_-

Si je comprends bien, en JS, la différence entre for..in et for..of c’est un comme la différence entre foreach ($table => $element) et foreach ($table as $element) du PHP.

L’un place dans $element la clé, et l’autre la valeur.
En PHP, on peut même faire $table => $key as $value, où l’on obtient la clé et la valeur en même temps.

Sauf qu’en JS, on a aussi le for, forEach, .each(), et bien d’autres trucs…

Putain, ça m’énerve : le flux RSS de ce site est cassé 80% du temps !

La raison ? Parce qu’ils "coupent" les anecdotes (raison légitime : ils veulent qu’on vienne sur leur site pour lire).

Sauf que… ils coupent l’anecdote après un certain nombre de caractères. Comme si je coupais la chaîne « bonjour comment ça va ? » après 10 caractères, ce qui donnerait « bonjour co… ».

Le problème, c’est qu’on fait ça normalement en comptant les octets : Le 10e caractère débute après le 10e octet. Or, certains caractères, en particulier tout ce qui n’est pas ASCII, et en UTF-8, se codent sur plusieurs octets. C’est le cas de tous les caractères diacritiques (éàçèâê, etc.), qui sont codés en utilisant entre 2 et 4 octets.

Du coup, quand le 10e caractère est un diacritique, et qu’on coupe à 10 octet, on se retrouve en plein milieu d’un caractère et on se retrouve avec une erreur, le fameux « � ».

Et donc, les parseurs XML (du lecteur RSS) renvoient une erreur.

À la louche, je dirais que 1 caractère sur 20~25 est un diacritique en Français. Dit autrement, le N-ième caractère dans une anecdote a 1 chance sur 20 d’être un diacritique et de poser problème. Si le flux RSS contient 20 entrées, on a à peu près sûr que le flux est cassé la totalité du temps.

Il y a une solution à ça : juste dire que l’on ne doit pas couper au N-ième octet, mais au N-ième caractère, en disant au programme qui coupe les anecdotes « attention, certains caractères font plusieurs octets ».
En PHP, on fait ça en utilisant « mb_string » (où MB signifie « multibyte »).

J’en parle là : https://lehollandaisvolant.net/?id=20140424175730
Et pour le SQL : https://lehollandaisvolant.net/?id=20140504183832

La solution est SIMPLE : juste à remplacer une fonction par une autre et c’est bon.

Pourquoi ça m’énerve ?
Parce que ça fait plusieurs fois que je signal ça au site, et rien n’est fait. C’est pas le seul site qui tronque ses posts, mais c’est le seul qui pose problème comme ça.

Encore une fois, ça va être à moi (l’utilisateur) de devoir faire le boulot des webmaster. Y en a marre des incompétences ! Quand c’est pas ça, c’est une erreur d’encondage, ou un problème de format, ou de compression GZip, ou d’URL mal redirigée…

Au final, une simple fonction « récupérer une page web » c’est 5 lignes de code fonctionnelles, auquel on ajoute 5000 lignes pour corriger les erreurs parce que l’éditeur du site est un incompétent.

Dans le même gens, lisez ça : http://sebsauvage.net/wiki/doku.php?id=csv

ÉDIT : bon, finalement je résous ça avec ceci :

$string = iconv("UTF-8", "UTF-8//IGNORE", $string)

Ça prend la chaîne reçue (de la requête) en entrée et tente de la convertir en UTF-8. Si la fonction rencontre des caractères invalides, elle les supprime. La chaîne retournée est donc toujours du UTF-8 valide.

Par contre, visiblement, il y a un problème dans l’implémentation des bibliothèques UTF-8 depuis presque 10 ans et tout le monde s’en bat les steaks : http://php.net/manual/fr/function.iconv.php#108643
Ils conseillent de faire ça, en PHP :

  ini_set('mbstring.substitute_character', "none");
 $text= mb_convert_encoding($text, 'UTF-8', 'UTF-8'); 

Ça convertit de UTF-8 en UTF-8, mais en remplaçant tout ce qui est invalide par une chaîne vide (le "NONE").

Dans les deux cas, ça suggère que l’on possède déjà en entrée une chaîne en UTF-8, même cassée. Pour le moment, sur 165 flux RSS je ne vois pas d’erreurs, mais ça pourrait en poser. Je propose donc ceci :

  ini_set('mbstring.substitute_character', "none");
 $text= mb_convert_encoding($text, 'UTF-8'); 

Comme ça essaye de trouver le bon encodage dans une liste interne au serveur (définissable soi-même avec mb_detect_order()), puis de traduire ça en UTF-8.

Too damn accurate.

Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better idiots. So fare the Universe is winning.
— Rick Cook

C’est un peu ça.

Ouais, ceci afin que cette matrice de petites lumières affiche les bonnes couleurs au bon endroit au bon moment. Quel métier :D

(Ravi de revoir des news de ce blog BD, sinon ! Ça faisait longtemps :D)