Le Hollandais Volant

J’ai un problème dans Blogotext : parfois, quand je fais des requêtes trop vites, les tokens à usage unique sur mes formulaires POST n’ont pas le temps d’être mis à jour et seule la première requête est prise en compte.
Une des solutions a été de mettre les requêtes en cache dans le navigateur et de faire une seule grosse requête plutôt que 10 petites, donnant ainsi le temps aux requêtes de se faire (on fait rarement 10 clics par seconde sur une page web).

Je me dis d’aller voir dans d’autres projets pour voir comment ils s’en tirent (n’ayant jamais vu ce problème ailleurs) et trouver une solution.

Dans les codes que j’ai été voir :
– formulaires en GET (pas en post), donc une simple URL à copier-coller pour lancer une requête
– pas de token à usage unique
– pas de vérification de session (une URL d’une session fonctionne dans une autre session).
– heureusement, il y parfois une vérification de connexion à la session (on doit être connecté pour que l’URL fonctionne).

Visiblement la solution aux problèmes de sécurité c’est supprimer la sécurité.

Je veux bien qu’un moteur de blog ou un lecteur RSS ne soient pas des applications critiques et que les token CSRF c’est assez lourd, mais quand même : pas même vérifier la session, WTF O_o ?

J’ai quotidiennement ce problème dans mon métier, je suis sûr que vous connaissez ça.
Cette personne qui vient vous voir en disant :

“Gilles, je peux te déranger 5 minutes ?”

En réalité, juste en posant cette question, elle vient déjà de me déranger 20 minutes alors que je ne lui ai pas répondu.

S’il vous plaît, respectez l’état de concentration, de “transe” des développeurs.

Ben oui, c’est bien connu : les systèmes d’exploitation, les Facebook ou Google, les HTML et PNG, les algo et tout le reste, ça tombe du ciel sur un CD que t’as juste à mettre dans le lecteur de ton ordinateur, lui aussi apparu sur le marché du jour au lendemain…


… et surtout pas grâce à 70 ans de recherche en nanotech, quantique, matériaux, chimie, optique et en logique, langages, électronique, prog par des gens ayant 160 de QI pour imaginer, concevoir, créer concrétiser et améliorer des machines qu’on utilise du bout des doigts.

Mais tout ça n’est pas grave : même la plus inintéressée des personnes ne peut nous retirer la joie et l’excitation de voir son tout premier morceau de code afficher « hello world » sur un terminal en noir et blanc, même après 42 compilations ratées :D

Le code source d’Apollo 11, la première mission qui a envoyé des gens sur la Lune et les a ramené sur Terre, vivants. L’ensemble a plus de 40 ans.

C’est en assembleur et c’est le code source retranscrit à partir de sources en papier.

Une petite remarque à propos des lecteurs RSS : si j’ai fait mon lecteur RSS perso, c’est parce qu’il n’y en avait aucun qui ne fonctionnait comme je voulais.

Un des problèmes que je voyais, c’est le temps de chargement entre chaque lecture : à chaque ouverture de post, le navigateur contacte le serveur pour recevoir le contenu de l’article qu’on demande à lire. Entre le moment où l’on clic et le moment où le contenu arrive dans le navigateur, il s’écoule un temps où on ne peut rien faire et c’est chiant.

Le problème quand l’interface et la BDD ne se trouvent pas sur le même système, c’est de synchroniser les deux. À la fois pour le contenu et pour le les actions de l’utilisateur.

Mon lecteur, c’est l’ensemble des éléments non-lus qui se trouve dans le navigateur : donc pas de requête serveur pour obtenir le contenu d’un article, le navigateur l’a déjà. Oui, la quantité de données dans le nav peut sembler importante, mais c’est relatif : 500 articles, ça fait ~2,2 Mo. C’est beaucoup, mais c’est à peine plus que le poids moyen d’une page web aujourd’hui. Ça charge en 3 secondes avec une connexion 8 méga. Ce délai est unique, juste au chargement.

Ensuite, pour la sync des interactions utilisateur (marquage comme lu, etc.), je fais un cache dans le nav : plutôt que de faire une requête serveur à interaction lu, je ne sync que tous les 10 articles lus. C’est là aussi beaucoup plus rentable.

Ce qui prend du temps, aujourd’hui, ce n’est plus la quantité de données à transférer, mais la quantité de requêtes faites au serveur. 10 connexions de 1 Mo sont beaucoup plus lentes que 1 connexion de 10 Mo.
De même pour les requêtes SQL : faire une seule requête pour marquer 10 articles comme lu, c’est plus rapide que 10 requêtes pour un article.

Mouahaha !

Besoin d’inspiration pour des UI ?
Ce site montre des tonnes d’UI différentes, taguées par catégories.

On ne fait pas assez attention au code qu’on exécute sur nos PC.

Et pas juste les n00bs ou les simples utilisateurs, mais aussi les codeurs, y compris de l’Armée US et d’autres institution « critiques ».

Blog sympa à propos de tout ça ↑

Y a aussi des liens intéressants chaque semaine (voir les la semaine en pixels).

Une petite réflexion sur le KISS.

En ce qui me concerne, je ne comprends pas trop le bordel autour de ça. Je pense qu’il est préférable d’avoir un programme opérationnel « out-of-the-box » mais qui puisse être customisé comme on veut.

KDE est un exemple comme ça : oui, il fait le café et le thé, mais c’est un environnement de bureau : il est là pour être le point central de l’interface utilisateur. C’est normal qu’il possède des options et des modules en tout genre.
Gnome était pareil : les options étaient simplement cachées dans une interface bordélique et difficile d’accès (dconf/gconf).

Je préfère un outil qui fasse tout mais bien plutôt que 15 outils différents avec un logo « kiss » façon « vu à la télé » qui vont alors fonctionner différemment, être mis à jour différemment, et ne pas être intégré les uns avec les autres.
Pour prendre un parallèle hors des programmes, prenons le smartphone : perso je préfère me trimbaler avec un smartphone unique qu’avec plein appareils séparés (photo, téléphone, internet, blog, gps, carnet de note, réveil, console de jeu…). Quand c’est bien fait, je n’ai pas de problème, le kiss n’est qu’une philosophie, voire une mode, qui ne peut pas être appliquée partout, qui ne soit même pas voulu partout.

Enfin, faut pas confondre une commande basique (cp, rm…) d’un programme tel que LibreOffice ou Firefox.
Je sais que certains préfèrent avec gNuméeix, Abiword ou Dia plutôt que LibreOffice car ce dernier n’est pas kiss car faisant plus d’une seule fonction. Les mêmes préféreront avoir des vidéos désintégré du navigateur (qui doit alors faire du HTML seul) pour les lire dans VLC à part. Mais qu’importe, tant que tout le monde puisse voir les vidéos, c’est le plus important.

Pour répondre à la question du titre du coup, non le Kiss ne convient pas pour tout, ni à tous.

Sur certains serveurs, file_get_contents(), copy() et quelques autres fonctions qui peuvent fonctionner avec des URL (chemins distants) ne marchent pas : la directive INI allow_url_fopen est mise à Off.

Pour palier à ça, on peut utiliser cURL pour récupérer le fichier. Sur les serveurs qui n’ont que cette directive mise à Off, cURL (s’il est installé) fonctionnera.

On utilisera alors ça :

// request
$curl_handle = curl_init();
curl_setopt($curl_handle, CURLOPT_URL, $url);
curl_setopt($curl_handle, CURLOPT_RETURNTRANSFER, 1); 
$file_content = curl_exec($curl_handle);
curl_close($curl_handle);
// saving
file_put_contents($file_name, $file_content);

Dans les cas où le serveur bloque toutes les connexions sortantes, il n’y a pas de solutions pour faire des requêtes externes.

Quand on produit des PNG avec PHP/GD, les images sont rarement optimisées. Cette page donne quelques pistes.

Moi par exemple, je tente de reproduire ça en plus léger.
En somme, c’est une simple matrice 5x5 avec deux couleurs dans la palette.

Il me suffit d’ajouter ça, juste avant le imagepng() :

imagetruecolortopalette($image_ressource, false, 256);

La taille d’une icône 512x512 passe ainsi de 2 131 octets à 283 octets (~85% de réduction).

L’image passée dans optipng me revient à la même taille. Pour les icônes avec très peu de couleurs c’est donc idéal. Pour les autres png, voyez l’article.

iconv, uchardet, recode : deux utilitaires pour respectivement convertir des données d’un charset à un autre et pour détecter le charset d’un fichier, et un troisième en bonus pour faire la même chose.

Comme ça plus de problèmes d’encodage.

(UTF-8 Powa!)

Certains serveurs envoient une valeur d’entête pour "Content-Type". D’autres en "content-type".

Ce qui change ? Deux majuscules.
Ce que ça change ? Tout.

Visiblement le RFC autorise les deux écritures et même d'autres.

Vous voulez parser du HTML ? Vous voulez juste récupérer une page web ? Vous allez en chier :
http://lehollandaisvolant.net/?id=20150723122310
http://lehollandaisvolant.net/?id=20160130195532

Certains me diront que c’est pour ça que d’autres ont inventé des lib toutes prêtes qui couvrent 100% des cas.
Sauf que parfois on est con et on a envie de réinventer soi-même la roue (c’est comme ça). Ouais, ben si techniquement ça sert à rien, ça permet au moins de voir l’ampleur du merdier.

Et tout ça, c’est après avoir inventé les normes, les RFC et tout ça. Si ça n’avait pas été le cas, le merdier serait des années lumières plus gros.


Mais tout ça c’est la loi de Murphy : il y a aura toujours un clampin rigolo pour faire à l’inverse de ce que tous les autres se sont accordés à faire. Même s’il a le droit. Même s’il a raison.

Exactement.

L'expérience permet non seulement d'apprendre à faire de bonnes requêtes pour un moteur de recherche, mais elle permet également de lire les docs et de reconnaître les bonnes sources.

Et ça, aucun cours magistral ne me l'apprendra.