:/

C’est pour ça qu’il ne faut pas être surpris des applications qui, de plus en plus, se payent par abonnement (à commencer par des trucs Microsoft, ou Google) : ça assure un revenu continu et permet de voir sur le long terme (même si avec 100 G$ de cash, on peut voir l’avenir sereinement, concernant M$ ou Google).

Alors certes, pour un OS à 300 €, on est en droit d’avoir les mises à jours durant 5 ans… Mais pour une appli vendue 1 € sur le Play Store, ce n’est pas viable pour un dév de la vendre une fois et de proposer des mises à jours indéfiniment. Pourtant, si on veut qu’une app, même une petite app, reste à jour, sécurisée, suive les versions d’android, évolue avec la technologie… il faut du travail. Beaucoup de travail.

Le code, c’est réécrire constamment des portions du code avec des nouveaux trucs. Un peu comme réécrire des portions d’un livre pour suivre les évolutions du langage et toujours être compréhensible par tout le monde. La langue n’évolue pas vite, mais imaginez avoir à traduire un pavé comme la Bible de l’an 1 à l’an 2019, de l’hébreux, au français moderne, en passant par le latin et toutes les étapes intermédiaires.

Je comprends tout à faire la recherche d’un modèle qui dure dans le temps (pub, abonnement…), même si je n’approuve pas forcément toutes les solutions, et même si je n’ai pas moi-même de solution.

**

J’en profite pour le dire : soutenez les petits dév.

Ce sont de vrais gens qui font les applis à 1 € dont vous vous servez tous les jours. Surtout s’il n’y a pas de pub et que l’app est gratuite et que la version payante est basée sur le volontariat.

1 € ce n’est rien. Même si ça vous arrive une fois par mois.
Mais pour une application qui n’a même que 5 000 téléchargements, ça représente pas mal pour le développeur. Un salaire, en fait : de quoi vivre et abreuver le monde de nouvelles applications.
Il ne s’agit pas de mettre une pièce dans le téléphone à chaque fois qu’on utilise une app, mais une seule fois. Rien que ça, ça permettrait de faire vivre beaucoup de dév.

En tant que blogueur et codeur, en 10 ans, si chaque visiteur avait mis 1 centime dans son ordi la première fois qu’il a visité mon site, j’aurais touché assez pour ne plus avoir à me soucier de l’avenir, financièrement parlant.

C’est pour ça que je pense que, les modèles comme Patreon ou Tipeee sont pas mal, même si elles ont leur limites.
Un avantage, c’est que chacun peut donner combien un veut, peut, ou combien il estime que ça vaut.

J’ai ma propre page Tipeee, BTW, pour Couleur-Science pour le moment (pour voir). Il y a déjà eu quelques dons (le compteur est mis à 0 tous les mois sur leur site, j’en ai eu 4 ou 5 de montants variés) merci à vous !

Je pense l’ouvrir aux autres trucs (blog, outils en ligne…).

Un comparatif de différents systèmes d’encodage de données (JSON, XML, Avro…)

C'est dingue : à chaque fois qu'il dit "tôt ou tard vous aurez à faire [...]" je me vois dans le cas qu'il décrit...

Pareil, y'a tout un tas de petites astuces bien utiles.

C'est long, mais je conseil à chaque programmeur de lire ça quand même, et de garder ça sous le coude.

0 VS Null

L’image directe : https://pbs.twimg.com/media/D3EXyb7WoAASPpX.jpg

On pourrait ajouter undefined : il suffirait de retirer le porte rouleau.

ÉDIT : Ah ben voilà : https://twitter.com/Artheriom/status/1113085796117082112 :)

Pas forcément fan de tout, mais il y a néanmoins de bonnes astuces et conseils.

Je veux bien que les dév soient des humains, même chez Microsoft ou Google, mais y a des erreurs qu’on s’attendrait à ne pas voir dans un code aussi utilisé, aussi testé (et aussi cher) que le leur.

Par exemple, comparer des chaînes de caractères avec une fonction pour comparer des nombres…

C’est plus une erreur là, c’est de la négligence, voire de l’incompétence.

Les Services Workers JS sont pratiques, mais bordel que c’est chiant à débugguer !

Je suis obligé de mettre des console.log() à toutes les lignes pour savoir ce qui se passe :o

Ici, c’est *juste* la fonction qui intercepte les requêtes réseau de la page (toutes les requêtes : XHR, mais aussi les fichiers scripts, les CSS, les fonts, les background-image()…).

La fonction permet de voir :
– si une requête doit être mise en cache (fichier, image) ou pas (requête de type json/ajax).
– si elle doit être mise en cache, alors on regarde si le fichier s’y trouve. Si oui ? retourne le fichier. Si non ? fait une connexion réseau. La connexion, fonctionne-t-elle ? Si oui : récupère la réponse et la met en cache, puis retourne la réponse. Si non, emet une erreur.

Le truc c’est que pour que le script puisse prétendre être une bonne PWA, aucune requête ne doit finir sur une erreur (404 ou autre). Si l’app est offline, la requête ne marchera pas, mais l’erreur doit être gérée (normale, me diriez-vous, mais c’est assez lourd quand-même).

Autrement, une fois qu’on a notre fonction, comme ça, c’est à peu près tout ce qu’il faut pour transformer n’importe quelle page web en PWA avec capacité de faire du offline (du moment qu’on séparre bien le shell de la page des données, d’où l’intérêt de travailler avec des requêtes Ajax qui envoie des données (json ou xml, html…) qui sont ensuite incorporées dans la page.

Le rendu est spectaculaire et 'achement rapide.

Regardez sur le site de Stéphanie Walter (sous Firefox) : c’est rapide comme l’éclair ! https://stephaniewalter.design/

Et pour cause : la gestion du cache est gérée par la page web (le service-worker) : il suffit de naviguer quelques pages pour que toutes les données soient mises en cache et après c’est super rapide : seulement 14 ko de données sont transférées pour la page d’accueil !

Et normalement ça fonctionne aussi en offline.

Oui, le navigateur a son propre cache… mais il est imprévisible, d’une part, et d’autre part il y a toujours des requêtes réseau de faites, qui vérifient si les cookies sont bons, si les ETAG sont modifiées, si le fichier n’a pas changé, etc.

Ici, les requêtes réseaux sont interceptées par le Service Worker.

Bien-sûr, ce n’est pas une raison pour se lâcher et arrêter d’optimiser ses pages : cette rapidité doit servir à permettre un usage offline du site (c’est pratique pour lecteur RSS en JS par exemple). J’ajoute simplement le raccourcis sur le bureau android (ou iOS, ou Windows 10 comme "webapp") et c’est bon !

Si je suis en ligne, il rapatrie les données mises à jour, autrement il utilise ce qu’il possède en cache.

En plus, les navigateurs utilisent des bases de données locales pour les données en cache : on peut donc très bien utiliser des BDD pour nos données (pas besoin de rester au JSON/XML).

Ah ben si, ça existe : après le brainfuck et le whitespace, voici emojicode : fini les "function", "if", "echo" ! Maintenant on utilise ça :

🏁 🍇
  😀 🔤Hey!🔤❗️
🍉

Fini aussi les true/false, maintenant c’est 👍/👎.

:D

(via)

Toilet humor :)

(par contre c’est mal indenté)

don’t solve a problem you don’t have

+1

C’est aussi pour ça que les framework en tout genre (CSS/HTML, pour que je sache) sont si énormes même pour une simple page HTML : ils veulent traiter tous les imaginables pour que tout le monde les utilise, alors personne n’a besoin de tout à la fois.

Si vous ne savez pas quels seront les besoins futurs du client, alors c’est que le cahier des charges n’est pas bon, et que la vision des choses du client n’est pas claire, et donc qu’il faut peut-être clarifier tout ça avant de commencer à construire.

Quand une maison est construite, on ne met pas une masse de briques en forme de maison dans laquelle on creuse ensuite des murs, puis des fenêtres. Non, on a une vision globale du projet avant de commencer et on s’en tient au plans.
On conserve parfois un peu d’espace pour les détails, mais ce sont justement des détails, pas un mur porteur ou une nouvelle pièce.

La transition est sympa :-)

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.