#19976

Brackets - A modern, open source code editor that understands web design.

Le 1er septembre 2021, Adobe mettra fin à la prise en charge de Brackets. Si vous souhaitez continuer à utiliser, gérer et améliorer Brackets, vous pouvez créer un fork du projet sur GitHub. Dans le cadre du partenariat établi entre Adobe et Microsoft, nous encourageons les utilisateurs à migrer vers Visual Studio Code, l’éditeur de code open source gratuit de Microsoft.

Brackets, l’éditeur de code d’Adobe, c’est fini.
Ou plutôt, c’est son support officiel par Adobe qui est fini.

Parmi les éditeurs de code, ils proposent VSCode (de Microsoft). On peut également citer Atom (par Github, donc Microsoft), ou Notepad++ (plus léger, mais libre).

En ce qui me concerne, je conseille plutôt grandement SublimeText : https://www.sublimetext.com/

La version gratuite est complète mais vous affichera un popup régulièrement. Si vous achetez une licence, elle sera active à vie et n’importe où (ÉDIT : la licence est active à vie, mais ne couvre que 3 ans de mises à jour). Perso j’utilise ma licence sur plusieurs PC (des PC à moi).

Bref, c’est pas gratuit (80 $, ce qui reste abordable — ce n’est pas Office ou Photoshop, je veux dire), mais ils ne sont pas chiants avec ça et le logiciel vaut clairement le coup selon moi.

(Merci à Yves pour l’info !)

https://brackets.io/

#19934

GitHub - graphicore/librebarcode: Libre Barcode: barcode fonts for various barcode standards.

Sick m’envoie cet outil, qui permet d’afficher un code barre à partir d’un texte. Merci à lui !
Plutôt utile : https://graphicore.github.io/librebarcode/

L’outil utilise une police spéciale, qui associe chaque lettre aux barres verticales du code barre. En plus de ça, l’outil calcule le caractère nécessaire (dans la police) pour les barres dédiées à la somme de contrôle et faire un code barre compatible EAN (la norme qui régit ça). Ceci nécessite du JS.

Je pensais le mettre dans ma collection d’outils.

Ça doit pas être bien lourd, hein ?

Mouais, sauf qu’on est en 2021 : c’est pas pèse pas une tonne, c’est que c’est nul. Par conséquent, sur la page Github du projet :

You'll need git, bash, python3.6, node […] nvm, with npm, bower and ttfautohint […]. Maybe you'll have to install the python3-venv module.

Et l’archive pèse 1,8 Mo. Et ça c’est l’archive compressée, car décompressé y en a pour 6,2 Mo.

6 397 706 octets d’octets pour créer un code barre

Je n’ai pas essayé de refaire l’outil (encore), mais 6,4 Mo, c’est plus que pour faire un moteur de blog qui fait aussi gestion des liens, de notes, de commentaires, de fichier, de contacts, agrégateur RSS et agenda… décompressé, tout compris.

Un créateur de code barre, ça devrait pouvoir tenir dans 6,4 KILO-octets.
HTML et CSS inclus.
Bordel.

Donc je vais voir si y a pas un outil similaire mais avec un poids décent, ou bien de couper à la hache les trucs qui vont pas là-dedans.

Pourquoi quand ils font les lib comme ça, ils font pas juste le fichier centrale du programme d’un côté, et éventuellement toute l’appli décorée bien fancy qui requiert cinq IDE différents, et 4 framework à la mode de l’autre ?

https://github.com/graphicore/librebarcode

#19904

Il réduit les temps de chargement de GTA Online : Rockstar le remercie et prépare un update | Les Joies du Code - Humour de développeurs : gifs, memes, blagues

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.

https://lesjoiesducode.fr/reduit-temps-chargement-jeu-gta-online-rockstar-games-update

#19901

3 outils très pratiques pour archiver sa vie numérique ! | dbeley

Ç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.

https://dbeley.ovh/post/2021/03/15/3-outils-très-pratiques-pour-archiver-sa-vie-numérique/

#19788

Components: Server-Side vs. Client-Side | CSS-Tricks

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.

https://css-tricks.com/components-server-side-vs-client-side/

#19752

Note : adieu Flash

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

Press F to pay respect.

H.

https://lehollandaisvolant.net/?mode=links&id=20201231205455

#19742

VSCodium - Open Source Binaries of VSCode

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)

https://vscodium.com/

#19164

Is Web Design Easier or Harder Than it was 10 Years Ago? | CSS-Tricks

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 ?

https://css-tricks.com/is-web-design-easier-or-harder-than-it-was-10-years-ago/