Journal
Ce journal contient 4 entrées.
Drag&Drop HTML pollué par Flash
Il est très probable que ce soit un problème dans l'implémentation du drag&drop de Firefox. Je suppose qu'il doit détecter dans quelles surfaces le drag&drop doit être délégué à un plugin externe (en l’occurrence Flash), mais que cette détection ne doit pas tenir compte de quel onglet est réellement dessiné. Il serait intéressant de voir si le problème persiste (i) lorsque les deux pages sont dans des fenêtres différentes et (ii) lorsque d'autres plugins sont utilisés, comme par exemple une applet Java.
Dans tous les cas, se débarrasser de Flash ne peut être qu'une bonne pratique.
Dans tous les cas, se débarrasser de Flash ne peut être qu'une bonne pratique.
[code] Trouver les erreurs - LinuxFr.org
En référence à Heartbleed (voir http://benjaminbillet.fr/news/index.php?link=d5gw3m), voilà un petit récapitulatif/comparatif des méthodes de détection d'erreur dans les programmes informatiques.
On y apprend notamment que le taux d'erreur varie, en général, entre 1 et 25 défauts pour 1000 lignes de code, qu'un développeur de la NASA détecte 3 erreurs par heure d'effort et que 80% des erreurs se trouvent dans 20% du code.
On y apprend notamment que le taux d'erreur varie, en général, entre 1 et 25 défauts pour 1000 lignes de code, qu'un développeur de la NASA détecte 3 erreurs par heure d'effort et que 80% des erreurs se trouvent dans 20% du code.
Gestion des cas d'erreur : les exceptions
De bonnes pratiques pour la gestion des exceptions vérifiées/non vérifiées.
Toutefois, les exceptions non vérifiées, c'est-à-dire celles que le développeur n'est pas obligé de gérer pour pouvoir compiler son programme, posent un problème majeur : on ignore, à tout moment, quelles exceptions vont être retournées par les méthodes que l'on invoque.
Lorsqu'un programme devient assez gros, la plupart des méthodes font appels à d'autres méthodes et ainsi de suite. Si les librairies ne documentent pas précisément quelles sont les exceptions non vérifiées qui peuvent être lancées, alors il n'y a qu'à l'exécution que l'on se rendra compte que des erreurs surviennent en masse.
Toutefois, les exceptions non vérifiées, c'est-à-dire celles que le développeur n'est pas obligé de gérer pour pouvoir compiler son programme, posent un problème majeur : on ignore, à tout moment, quelles exceptions vont être retournées par les méthodes que l'on invoque.
Lorsqu'un programme devient assez gros, la plupart des méthodes font appels à d'autres méthodes et ainsi de suite. Si les librairies ne documentent pas précisément quelles sont les exceptions non vérifiées qui peuvent être lancées, alors il n'y a qu'à l'exécution que l'on se rendra compte que des erreurs surviennent en masse.
PHP : fread + filesize = danger
Je n'aime pas trop taper sur PHP, mais quand la documentation elle même n'est pas fiable et me fait perdre une bonne demi-heure, ça a tendance à me gonfler.
La documentation de fread (http://www.php.net/manual/fr/function.fread.php) donne un exemple (un vrai exemple hein, officiel, pas un commentaire) pour lire un fichier en entier :
$contents = fread($handle, filesize($filename));
Alors oui, sauf que dans la documentation de filesize il y a une petite note qui dit "les résultats de cette fonction sont mis en cache" (http://www.php.net/manual/fr/function.filesize.php).
Ce que ça signifie c'est que si vous écrivez/lisez plusieurs fois d’affilée dans un fichier, la taille du fichier retournée par filesize ne changera pas (et donc, fread lira trop ou pas assez de données).
C'est génial quand on ne le sait pas, parce que c'est sincèrement la dernière chose à laquelle on pourrait penser. Une fonction qui s'appelle "filesize", on ne peut pas imaginer qu'il y ait un piège idiot, qui plus est lorsque c'est la documentation qui vous donne le bout de code en question.
Au début, je n'y ai pas cru, alors j'ai écrit un test qui crée deux chaînes, une de 500 caractères et une de 1000:
1/ Les 500 caractères sont écrits dans le fichier puis lus.
2/ Les 1000 caractères sont écrits dans le fichier puis lus.
3/ 1 et 2 sont réitérés avec cette fois l'utilisation de clearstatcache(), qui vide le cache des tailles, entre autres.
<?php
save('file_test', str_repeat('x', 500));
echo strlen(load('file_test', false)) . ' ';
save('file_test', str_repeat('x', 1000));
echo strlen(load('file_test', false)) . ' ';
save('file_test', str_repeat('x', 500));
echo strlen(load('file_test', true)) . ' ';
save('file_test', str_repeat('x', 1000));
echo strlen(load('file_test', true)) . ' ';
function save($file, $data)
{
$fh = fopen($file, 'w');
fwrite($fh, $data);
fclose($fh);
}
function load($file, $clear)
{
if($clear)
clearstatcache();
$fh = fopen($file, 'r');
$data = fread($fh, filesize($file));
fclose($fh);
return $data;
}
?>
Et ce test, il affiche bien "500 500 500 1000", ce qui signifie que le fichier n'a été lu qu'à moitié dans l'étape 2.
Ce genre de problème est usant. Je ne critique pas ici le fait que filesize utilise un cache (c'est juste une propriété de la fonction), mais plutôt que la documentation de fread propose un exemple de code dangereux sans qu'à aucun moment ne soit indiqué que celui-ci peut avoir un comportement aberrant.
Si vous voulez vérifier par vous même, j'ai fait une copie des pages de la documentation ici : http://benjaminbillet.fr/media/php_fread_filesize_doc.7z
Bref, utilisez file_get_contents...
La documentation de fread (http://www.php.net/manual/fr/function.fread.php) donne un exemple (un vrai exemple hein, officiel, pas un commentaire) pour lire un fichier en entier :
$contents = fread($handle, filesize($filename));
Alors oui, sauf que dans la documentation de filesize il y a une petite note qui dit "les résultats de cette fonction sont mis en cache" (http://www.php.net/manual/fr/function.filesize.php).
Ce que ça signifie c'est que si vous écrivez/lisez plusieurs fois d’affilée dans un fichier, la taille du fichier retournée par filesize ne changera pas (et donc, fread lira trop ou pas assez de données).
C'est génial quand on ne le sait pas, parce que c'est sincèrement la dernière chose à laquelle on pourrait penser. Une fonction qui s'appelle "filesize", on ne peut pas imaginer qu'il y ait un piège idiot, qui plus est lorsque c'est la documentation qui vous donne le bout de code en question.
Au début, je n'y ai pas cru, alors j'ai écrit un test qui crée deux chaînes, une de 500 caractères et une de 1000:
1/ Les 500 caractères sont écrits dans le fichier puis lus.
2/ Les 1000 caractères sont écrits dans le fichier puis lus.
3/ 1 et 2 sont réitérés avec cette fois l'utilisation de clearstatcache(), qui vide le cache des tailles, entre autres.
<?php
save('file_test', str_repeat('x', 500));
echo strlen(load('file_test', false)) . ' ';
save('file_test', str_repeat('x', 1000));
echo strlen(load('file_test', false)) . ' ';
save('file_test', str_repeat('x', 500));
echo strlen(load('file_test', true)) . ' ';
save('file_test', str_repeat('x', 1000));
echo strlen(load('file_test', true)) . ' ';
function save($file, $data)
{
$fh = fopen($file, 'w');
fwrite($fh, $data);
fclose($fh);
}
function load($file, $clear)
{
if($clear)
clearstatcache();
$fh = fopen($file, 'r');
$data = fread($fh, filesize($file));
fclose($fh);
return $data;
}
?>
Et ce test, il affiche bien "500 500 500 1000", ce qui signifie que le fichier n'a été lu qu'à moitié dans l'étape 2.
Ce genre de problème est usant. Je ne critique pas ici le fait que filesize utilise un cache (c'est juste une propriété de la fonction), mais plutôt que la documentation de fread propose un exemple de code dangereux sans qu'à aucun moment ne soit indiqué que celui-ci peut avoir un comportement aberrant.
Si vous voulez vérifier par vous même, j'ai fait une copie des pages de la documentation ici : http://benjaminbillet.fr/media/php_fread_filesize_doc.7z
Bref, utilisez file_get_contents...
Ce journal est basé sur Ginger, un gestionnaire de lien minimaliste développé dans le cadre d'un stage de perfectionnement. Pour plus d'informations, consulter le wiki consacré à mes projets personnels.