Il y a quelques temps, pour tester la fonctionnalité Wonder wheel de Google, j'avais dû switcher sur google.com. Le hic c'est qu'après ça, une recherche dans la barre de recherche me renvoyait systématiquement sur google.com et non google.fr.
Cela venait du fait qu'un cookie est posé sur le navigateur avec la langue par défaut à utiliser. Il s'agit du cookie "PREF" pour le domaine google.com et précisément de la portion "LD=en" qui est en cause. Supprimer ce cookie règle le problème.
Apparemment c'est bien google.com qui est interrogé par la recherche et qui redirige ensuite sur google.fr, mais ce que je ne saisis pas c'est pourquoi aller sur google.com depuis google.fr met à jour le cookie dans un sens alors que faire l'inverse ne le fait pas...
Hier, j'avais à parcourir un tableau d'objets (pouvant avoir potentiellement des centaines voire exceptionnellement milliers d'entrée) pour rechercher si l'identifiant de l'un d'eux se trouvait dans un second tableau. J'avais commencé par utiliser pour ça la fonction in_array() à chaque itération pour voir si l'identifiant de l'objet était présent ou non dans le second tableau.
En voyant cela, un collègue m'a fait remarquer que ce serait peut-être plus performant de construire un tableau dont les clés sont les valeurs du second tableau (via array_flip()) pour pouvoir utiliser isset() au lieu de in_array() et voici les résultats obtenus :
Structure du bench
Le bench consiste à rechercher 100 000 fois la même valeur dans le tableau array('11345', '7437', '7329', '45494', '7894311', 'sdfsdg', 'qsqsdcirt', 'd787 sdfs df'), avec trois méthodes différentes :
in_array()
array_flip() suivi de isset()
array_flip() suivi de array_key_exists()
Le test est effectué avec deux valeurs différentes : d'abord avec la première valeur du tableau (cas théoriquement le plus favorable puisqu'on arrête la recherche une fois la valeur trouvée) puis avec une valeur qui n'est pas dans le tableau (cas théoriquement le plus défavorable puisqu'on est obligé de parcourir tout le tableau). Le résultat en conditions réelles sera donc compris dans cette fourchette.
Cas in_array()
Code exécuté :
Cas favorable ($value = '11345') : ~0.33 secondes
Cas défavorable ($value = 'uottuyi') : ~0.52 secondes
Cas isset()
Code exécuté :
Cas favorable ($value = '11345') : ~0.12 secondes
Cas défavorable ($value = 'uottuyi') : ~0.09 secondes
Cas array_key_exists()
Code exécuté :
Cas favorable ($value = '11345') : ~0.27secondes
Cas défavorable ($value = 'uottuyi') : ~0.24 secondes
Et pour de plus petites quantités ?
Les grands volumes c'est bien mais qu'est-ce que ça donne quand on a peu d'itérations ?
Un test à 5 itérations au lieu de 100 000 donne environ le même résultat pour les trois méthodes : avec ~6E-05 secondes pour les méthodes 1 et 3 et ~5E-05 pour la méthode 2.
Tandis qu'un test sur une unique itération donne la première méthode gagnante avec ~4E-05 secondes contre ~5E-05 pour les deux autres (à ce niveau c'est le array_flip pour transformer les valeurs en clés qui coute cher).
Conclusion
À moins d'avoir toujours très peu d'itérations (moins de 5), la méthode passant par array_flip() puis isset() est d'assez loin la meilleure (environ quatre fois plus rapide sur des grands nombres et pas plus lente sur des petits).
En passant, on remarque aussi qu'avec cette méthode, rechercher une valeur qui n'existe pas dans le tableau est plus rapide que de rechercher la première valeur du tableau, même si je ne vois pas forcément trop pourquoi
Une petite extension développée par l'un de mes collègues et qui ne fait qu'une seule chose mais le fait bien : elle ajoute un bouton permettant de modifier d'un seul clic l'ouverture des onglets en passant d'une ouverture en arrière-plan à une ouverture en avant-plan, et vice versa. C'est pas grand chose mais dans certains cas c'est bien pratique ^^
Cette extension clairement réservée aux développeurs permet d'écrire une expression rationnelle et de tester en temps réel son application sur une chaine. C'est carrément pratique, en particulier quand on doit débuguer une expression écrite par quelqu'un d'autre et qui, forcément, est totalement incompréhensible \o/
Encore une petite extension qui n'a l'air de rien comme ça mais que je trouve bien pratique ! Elle permet de renseigner un champ de formulaire de type fichier directement en "droppant" le fichier dedans plutôt qu'en étant obligé de saisir sont chemin d'accès ou de le rechercher dans l'arborescence (alors que dans certains cas on a déjà fait cette recherche préalablement dans l'explorateur windows).
Certains caractères sont bien compliqués à saisir sur un mac et notamment pas forcément visibles sur le clavier (de mon macbook pro en tous cas, pour les autres j'en sais rien). Or quand on fait de développement, c'est caractères sont très souvent utiles :
~ (la tilde) : alt+N
{ (l'accolade ouvrante) : alt+(
} (l'accolade fermante) : alt+)
[ (le crochet ouvrante) : alt+shift+(
] (le crochet fermante) : alt+shift+)
\ (le backslash ou antislash) : alt+shift+/
| (la barre) : alt+shift+L
Faire une capture d'écran
Je ne sais pas si par hasard les iMac ont une touche équivalente à "Impr. écran" qu'on trouve sur PC mais en tout cas ce n'est pas le cas du MacBook pro. Leopard permet de capturer soit tout l'écran (cmd + maj + 3), soit une sélection (cmd + maj + 4), soit une fenêtre (cmd + maj + 4 puis espace). Dans tous les cas la capture sera automatiquement enregistré en PNG sur le bureau.
Forcer l'éjection du CD depuis un terminal
Après insertion, mon CD n'apparaissait pas dans l'interface (ni dans iTunes, ni dans le finder). Une courte recherche sur Google m'a sorti une panoplie de solutions possibles, la plus simple (et qui a marché dans mon cas) était de forcer l'éjection depuis le terminal via la commande drutil eject.
Il y a quelque temps, j'ai mis en ligne un pack de smileys pour le logiciel de messagerie instantanée Pidgin. Ce pack contient les smileys utilisés sur mes forums, comme je l'avais déjà fait pour Adium (car oui, Adium est excellent mais ne tourne que sur Mac, donc quand on est sous Windows, il faut se rabattre sur autre chose et Pidgin reste le moins mauvais que j'ai pu trouver...).
Pour générer ce pack, j'ai utilisé le convertisseur que j'avais déjà codé pour le pack Adium et qu'il serait temps que je finalise pour le publier...
Mais là n'est pas le propos de cette note. En effet, j'ai constaté plus tard, quand certaines personnes ont voulu exploiter ce pack, que le pack ne s'installait pas systématiquement. En fait le problème vient du fait que Firefox (de même qu'Opera et Safari dans leurs dernières versions) altère légèrement le fichier du pack qui est une archive gzip.
En effet quand j'ouvre le fichier téléchargé, au lieu de trouver directement dedans le fichier .tar que je devrais y trouver, je tombe sur une sorte de dossier intermédiaire du nom du fichier. Ce "dossier" apparait lors du téléchargement uniquement puisqu'il n'est pas présent sur le fichier avant l'envoi, pas plus que lors d'un téléchargement via IE6 (eh oui, j'ai encore de vieux trucs sur mon PC, même si je ne m'en sers que pour des tests ).
Je n'ai testé ça que sous Windows et je ne sais pas ce qu'il en est des versions Linux et Mac de ces différents navigateurs mais sur Windows le problème est réel (du moins pour des archives publiées via un site tournant sous WordPress, mais je ne pense pas que ça vienne de là).
Je soupçonne que ça puisse venir de l'aptitude qu'ont les navigateurs à recevoir de pages compressés en gzip par le serveur et de les décompresser à la volée : l'archive étant dans ce format, peut-être le navigateur fait-il un truc pas net avec ? Peut-être aussi qu'il y aurait des en-têtes particuliers à envoyer pour résoudre le problème... ou peut-être pas.
Quoiqu'il en soit, la solution la plus simple que j'ai trouvée pour l'instant reste de fournir une archive .zip contenant l'autre archive. Là, pas de problème, il n'y a pas d'altération.