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)

+1