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
Oui alors pardonnez mais NON.
Les Dell XPS sont des machines magnifiques, puissantes, très autonomes et j’adore les miens, mais leur clavier n’est pas fait pour programmer.
Je ne sais pas vous, ni les autres programmeurs, mais perso, j’utilise intensivement les touches "home", "End" ou "PgUp", bref, toutes les touches qui sont généralement sur la droite du clavier.
Sur ces portables, et sur beaucoup d’ordinateurs portables, en fait, ces touches sont refourguées en touches de fonction sur les touches fléchées (il faut donc faire Fn+Left pour avoir le "home"). Pire, sur les XPS les touches fléchées sont des demi-touches et c’est absolument MERDIQUE (à noter que Apple fait la même chose sur ses derniers mac-book-pro).
Pour ne rien arranger, le clavier sans fil Dell (de la même marque donc) est foutu de tel sorte que les touches citées plus haut sont tout en haut à droite du clavier (au dessus du pavé numérique). Ils sont là, mais ce n’est pas pratique.
Généralement, sur un clavier "normal", ces touches là sont accessibles sur le pavé numérique en désactivant le verrouillage numérique. Sur ce clavier Dell, il n’y a pas de bouton "num lock". Juste un bouton "CE" qui ne sert à rien. J’ai été obligé de remapper manuellement le pavé numérique pour avoir les touches home/pgUp/pgDn/… à la place du pavé numérique (que je n’utilise pas, je suis habitué à la barre numérique au dessus des touches alphabétiques).
Alors non, juste pour ça, je trouve que les XPS ne sont pas des ordis de prog (ni de jeu). Ce sont des très bons ordis, mais la disposition du clavier est à chier.
Une simple colonne supplémentaire à droite du clavier actuel, et remettre de vraies touches fléchées résoudrait tous les problèmes, mais autrement c’est la merde.
Je n’aime pas ça. C’est moche.
Il est donc impensable pour les designers de trouver un juste milieu entre un site tout bling-bling avec des animations absolument partout et une page sans CSS ?
Quant au fameux « ressenti utilisateur » il faut bien à un moment arrêter là aussi de se branler sur les Go de RAM dans les serveurs. Ajouter un super CPU et mettre 128 Go de RAM, c’est inutile si le script derrière est codé avec les pieds.
Apprenez à coder et à optimiser votre code !
L’ordre d’imbrication des boucles (for puis if, ou if puis for, ça peut tout changer…), le choix du moment où l’on fait son echo/appendChild, l’utilisation méconnue des "break" ou "continue", etc. ce sont ces choses là qu’il faut optimiser. Non je ne parle pas de grappiller des millisecondes. Inverser deux boucles imbriquées, ce sont parfois 300 ms de plus ou de moins. Sur un temps de chargement de 1s, c’est énorme.
Pendant 15 ans le web et le code a été écrit pour faire le truc le plus complet, le plus compatible et le plus fancy possible, sans tenir compte de la consommation des ressources système, tout simplement parce qu’on s’en foutait : il y en avait assez quoi qu’il arrive.
Aujourd’hui, l’ajout de hardware et la qualité du réseau ne suit plus bien. Il faut réapprendre à coder avec ta tête : non on n’a pas besoin d’un framework qui couvre toutes les fonctionnalités du monde. Un site web qui juste 3 boutons a besoin de 3 fonctions, pas 50 000 fonctions !
Faut apprendre à réutiliser sa tête, et ça c’est pas gagné…
Nan, c’est juste qu’ils ne permettent pas d’analyser des objets qui ont un trop grand nombre de niveaux d’imbrications. Le parseur en lui-même n’a aucun problème (je ne vois pas ça comme un soucis du parseur à proprement parler, c’est à dire le code qui va lire le JSON en entrée, bit par bit, et déclencher les fonctions qu’il faut au bon moment).
Selon l’article, Ruby plante à partir de 100 imbrications. C++ à 13 786.
C’est gênant, mais il faut bien une limite quelque part :/.
Il ne m’est jamais arrivé d’atteindre la limite sur le parsage du JSON. Par contre, j’ai déjà poussé à bout le moteur SQLite en PDO (qui a une limite de 1000 pour le nombre de variables que l’on peut mettre dans le prepare()).
Il me suffit alors de faire plusieurs requêtes plus petites au lieu d’un énorme.
