Le Hollandais Volant

dnw.

C’est cool de la part de Rockstar !
J’imagine que Nintendo, Sony ou d’autres studios un peu cons l’aurait attaqué en justice pour avoir décompilé leur binaires…

~

Sinon, d’un point de vu technique, ça semble être le problème similaire à ça :

for (var i = 0 ; i < tableau.length() ; i++) {
  // code ici
}

Pour les non-programmeurs : la boucle for permet d’itérer sur un tableau (qui est un ensemble de N variables à la suite). Chaque variable du tableau est repéré par son indice i.
Avec for, on commence par mettre i à 0 (pour la zéroième case, donc la première en fait). Ensuite, on vérifie que i est plus petit que la taille du tableau : si le tableau fait 10 cases, on doit pas chercher la case n°11 ou 12, mais s’arrêter à 10. Enfin, à chaque tour de la boucle for, on incrémente i : au second tour, on regarde la case 2, puis la case 3, et ainsi de suite.

Le problème ici ? c’est qu’à chaque tour de boucle, il effectue le calcul « i < tableau.length() », c’est à dire qu’il regarde le tableau, calcule la longueur, et voit si l’itérateur i est bien en dessous.

Si vous ne programmez pas, vous ne pouvez pas voir le problème, mais en vrai, calculer la longueur d’un tableau prend du temps. Et ici, ce calcul est fait à chaque bouclage.

La solution ? Calculer la longueur du tableau une fois, et mettre le résultat dans une variable :

var longueur = tableau.length();
for (var i = 0 ; i < longueur ; i++) {
  // code ici
}

Ou mieux, en JS comme en PHP, on peut faire ça, pour garder ça sur une ligne :

for (var i = 0, longueur = tableau.length() ; i < longueur ; i++) {
  // code ici
}

Notons qu’ici, on rajoute quelques octets de code, on rajoute une variable intermédiaire, mais on gagne énormément en vitesse : la longueur du tableau est calculée une seule fois au début.

En vrai, ceci est une de ces petites astuces à la con qui peut TOUT changer dans un code, et elle est applicable à tous les langages de programmation (à noter qu’on aurait pu utiliser également la boucle while).

Bref, ce genre de détails de code m’a déjà permis de gagner énormément de temps dans mes scripts.

~

Un autre exemple ? En JS, en manipulant le DOM : ajouter un élément HTML dans le DOM prend du temps : il y a l’ajout lui-même, le reflow (calcul de sa position sur l’écran et décallage des éléments déjà à l’écran), le repaint (son affichage effectif sur l’écran), etc.
Si l’on a une boucle for() qui ajoute itérativement plusieurs éléments, ne les ajoutez pas à chaque bouclage !

Faites plutôt un HTMLFragment, auquel vous ajoutez les éléments. Une fois la boucle for() terminée, vous ajoutez le HTMLFragment à la page. Au lieu d’avoir un calcul du reflow/repaint de la page pour chaque élément, on ne l’a qu’une seule fois.

Et ne vous dîtes pas « mais de toute façon je n’ajoute que 5 éléments ». Non : un jour vous vererz, votre boucle sera plus grande, de 1000 à 10000 éléments par exemple. Et là cela prendre un temps de malade et vous ne saurez pas d’où ça vient.

L’optimisation commence très bas et très tôt dans le code source.

~

Dernier exemple : mon blog utilisait autrefois un moteur de blog où chaque article, chaque commentaire était un fichier texte, dans un dossier correspondant au mois en cours. Un peu comme PluXML.
C’était assez lent, mais j’ai réussis à améliorer d’un coup la vitesse. Comment ? En partant du simple constat qu’un commentaire ne pouvait toujours qu’être posté après l’article qu’il commente.

Il était donc inutile de parser les commentaires de janvier-2010 pour un article datant de février-2010. Et vu que la page principale du blog n’affichait toujours que les derniers articles, cette page s’affichait toujours très vite.

Bon, depuis j’ai basculé mon blog sur du SQLite, bien plus rapide et plus adapté : on peut trier immédiatement les commentaires associés à un article. Les bases de données sont optimisés pour ce genre de tri, ce qui n’est pas le cas de PHP.

Ça me fait penser à mon vieil outil « Respawn ».

Faudrait quand j’aurais le temps (ie : jamais) faire un truc comme ça, où un script enregistre le DOM de la page (dont les styles, images…), le textualise, puis l’envoie côté serveur pour archivage.

Ça doit pouvoir se faire, si quelqu’un veut des idées pour se faire la main en JS/PHP (perso j’ai appris comme ça~).

ÉDIT : Hugo me signale cette extension Firefox/Chrome : https://github.com/gildas-lormeau/SingleFile

Sur une page web quelconque, un clic, et tout est enregistré dans une seule page (html + images + css + polices, pas le JS par contre). Le format est du simple HTML avec les ressources en Base64 incluses dedans. L’extension sauvegarde bien le DOM, et pas juste le HTML produit par le serveur. La différence est importante : regardez le code source (Ctrl+U) d’une page comme GMail ou Twitter : vous n’y verez rien, car le DOM (la page calculée) est produite dans le navigateur, par par le serveur.

Ça émule un peu le format MHT sous lequel le vieil Opera enregistrait une page web : c’était également du HTML+Base64.

+1

Mh… Autant l’Ajax a ses désavantages (j’en explique un dans un récent article), autant parfois c’est pas mal.

Perso je l’utilise pour les éléments interactifs. Un blog, ce n’est pas interactif (au sens « inter-actif ») : l’article s’affiche, on le lit et ça s’arrête là.
Un lecteur RSS par contre, j’appelle ça interactif : les différents articles sont là dans une liste, on clic dessus pour les ouvrir, ils sont marqués comme lus, on les organise en dossier, on les trie… Bref, l’utilisateur agit sur la page. Même chose pour un agenda, ou un bloc note : on ouvre une note, on la modifie, on la referme…

Pour ces données là, j’utilise Ajax et JSON.
La page web (l’arbre DOM) est emmené à être modifié massivement quoi qu’il arrive à cause de cette interactivité. Du coup, est-ce bien utile de rendre le HTML côté serveur ? Perso j’ai pensé que non : le navigateur reçoit les données en JSON et construit la page lui-même. Vu que la page va changer, le navigateur doit déjà avoir les fonctions pour la reconstruire sans arrêt, donc autant s’en servir pour construire la page la première fois.

Le seul « soucis » c’est quand les données sont nombreuses. Rendre 1 000 éléments <li></li> parce que l’on a 1 000 éléments non-lus dans son lecteur RSS, ça peut être un peu long. De même pour la réception des données.

Pour ça, pour le RSS j’ai adopté la stratégie du contenu partiel : au chargement de la page, le JSON contient le titre du post RSS et sa date (en fait, tout sauf le contenu, plus lourd). Ensuite je fais une seconde requête pour récupérer le contenu. Comme ça, la page s’affiche très vite et les données sont rapatriées en arrière plan. Le tout, sans avoir d’animation « chargement » ou « patientez svp » qui ne servent à rien.
Une solution alternative pourrait être de se limiter à charger 100 éléments, et à les charger 100 par 100 sur demande. Dans le cas où on a juste une liste d’éléments, ça marche. Si on a des dossiers de flux RSS, ça ne marche plus.

Bref, y a des choix à faire et faut rester intelligent et pas tout jeter à la poubelle. Ce n’est pas simple de trouver le juste milieu, encore moins quand on a des contraintes de débit internet, par exemple.

N'oubliez pas, webdevs de tous horizons : ce soir, c'est la fin officielle d'Adobe Flash.

Press F to pay respect.

H.

Je cite le site :

Why Does This Exist

Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking. According to this comment from a Visual Studio Code maintainer:

Donc le code source de VS est libre, mais le produit final distribué par Microsoft ne l’est pas, et ils y incluent des trackers.

VSCodium est donc VSCode sans les trackers Microsoft, directement compilé et prêt à l’emploi.

Le problème est le même que le problème de Chrome dont Chromium est la solution : la même chose, sans Gafam dedans (d’où le nom, d’ailleurs, je suppose).

(Merci à Roland Danard pour l’information)

Infaillible xD

Non, ce n’est pas une blague !

Ce langage reste très utilisé dans le domaine de la finance et des assurances.

Voilà ça c'est fait. D'autres questions tant qu'on y est ?

Belle illustration de la différence While / Do While :D

Chatted with someone who’s been working at a company as a front-end developer for 3 years. Their friend asked them to help build a website, but they had to decline. They didn’t know how.

Haha, c’est un des problèmes de produits tout faits tout prêts : ça empêche d’apprendre.

Bien-sûr, si le site devient un gros truc, il faut partager le taf et se spécialiser (front, back…), mais de là à ne même plus savoir écrire un index.html sans fautes tout simple, et à partir de là pour faire pousser le projet… Sérieux ?

Ah mais voilà un truc qui serait pratique, effectivement !

Cela dit, si les fanatiques de l’IA font leur job correctement, et que, comme ils disent, un jour les programmeurs seront inutiles, on pourra le faire.

Sauf que ça : https://www.commitstrip.com/fr/2016/08/25/a-very-comprehensive-and-precise-spec/

Et le machine learning comme avec Translate ne marchera pas car la plupart des langages n’ont pas d’équivalences en d’autres langages, car les applications ne sont pas les mêmes…

Le WebAssembly devient un standard du Web.

(via)

Affichez Couleur-Science dans un navigateur.
Mettez-vous en hors-ligne (dans Firefox : Touche "Alt" > Fichier > Travailler hors connexion)

Rechargez la page de Couleur-Science.

:D
Ça reste affiché avec un message spécial « offline ».

Bref, le site est dispo en PWA très basique.

Il n’y a pas de fonction de stockage local des articles, je n’en vois pas trop l’intérêt sur un blog comme le miens, mais ce genre de mini-PWA permet surtout de mettre en cache local très rapide certains fichiers utilisés par le site.

Les pages se chargent très rapidement après ça (et je ne cache pas (jeu de mot) que les moteurs de recherche aiment bien la SEO aussi).

Par contre, tant qu’on est en hors-ligne, ça n’affichera toujours que ce message là.

Les PWA permettent bien plus, ceci-dit. Au lieu du message « vous-êtes hors-ligne », on peut faire (tout en JS) un système de sauvegarde hors-ligne du contenu des articles, et une navigation hors-ligne également.
Dès qu’on repasse en ligne, le site récupère la page normalement.

Ce que j’ai fait là (je bricole :D) tient en quelques lignes de JS. Je ferais peut-être un article pour expliquer tout ça : c’est très rapide à faire.

De plus, ça permet aussi, sur mobile, d’afficher votre site en plein-écran et de le mettre sur le bureau avec une icône personnalisé. D’ailleurs, sur Firefox Android, une petite icône de maison a dû apparaître dans la barre d’adresse (je dis normalement car j’ai pas regardé, j’ai un maître-chat sur les genoux :-)).

M’enfin c’est cool, je bricole du JS.

--

Autrement, concernant CS : j’ai toujours essayé d’avoir quelques articles sous la main histoire d’avoir un rythme de publication régulier.

J’avoue être passé par une période un peu "vide" depuis 3 mois. Je n’ai pas d’explications pour ça, parfois c’est juste un peu dur d’écrire, ça vient pas (ou peut-être mon nouveau taf, depuis juin, qui me prend pas mal de temps).
Ça ne s’est pas trop vu grâce à ce stock tampon d’articles, que j’avais écrit à une époque où j’étais très inspiré.

Je viens de reprendre l’écrire d’un gros tas d’article (je suis plein jusqu’en mars 2020 là — où le blog fêtera ses sept ans :D).
Les articles sont à peu près rédigés, il me reste à les relire, les illustrer avec mes schémas et les retoucher un peu.

Bref, les blogueurs, et tout créateur connaît ça je pense.

--

Je suis aussi nettement moins actif sur LHV et côté prog. Mais je ne délaisse pas le blog.

Niveau prog, je code surtout pour moi, et en ce moment je suis plutôt satisfait de mon petit écosystème en ligne (liens, RSS, blogs, notes, agenda, outils en ligne…). C’est pas ce qu’il y a de plus puissant, mais ça me suffit.

Pour le blog, he manque de temps, et je publie davantage dans mes liens « au fil du web ».

Bref, bonne soirée à tous :-)