Générateur automatique de visualisation de site

Un nom qui ne donne pas très bien en français, mais j'ai développé avec une petite équipe un générateur automatique de visualisation de site.

Le principe est simple : on donne une url au générateur qui nous retourne une image qui est une copie d'écran du site qu'on aurait eu dans notre navigateur. Le coeur du générateur utilise le moteur Gecko pour le rendu de la page web.

Une démo du service de génération de visualisation de site est disponible en ligne, et l'idée est de développer une puissant API pour interfacer le service. L'idée principale de l'API est d'utiliser une url de callback qui permettra au service directement de retourner l'image une fois générée afin d'éviter au client de devoir poller pour controler si l'image est créée ou pas.

Les possibilités du service sont les suivantes :

• Taille des images paramétrables (120x90, 160x120, 320x240, 640x480, 1024x768)
• Format d'image JPEG ou PNG
• Ajout de délai avant la capture (pour les sites en flash par exemple)
• Mise-à-jour hebdomadaire, mensuelle ou annuelle des captures

Les feedbacks sont bien évidemment encouragés, et d'autres news sur l'API & CO suivront.

Uniqid ou la contre-intuitivité des arguments

D'après le manuel PHP, le prototype de la fonction uniqid est le suivant :

string uniqid ( [string prefix [, bool more_entropy]] )

Le deuxième paramètre à l'air réellement intéressant, dans la mesure où il assure une meilleure unicité de la chaine produite. Une propriété qui de toute évidence nous intéresse si on utilise cette fonction uniqid.

Sans s'étendre sur la probabilité de collision entre les 2 appels (ce que j'étendrai plus longuement dans un autre article), je voulais juste montrer la différence de vitesse d'exécution qu'induisait ce paramètre more_entropy. Un petit script faisant 100 appels à uniqid avec une valeur possible du paramètre, nous donne le résultat suivant (!) :

100 * uniquid(mt_rand()) en 0.799283981323 seconde

100 * uniquid(mt_rand(), true) en 0.00346183776855 seconde

Chose extrêmement intéressante, le temps d'exécution de la fonction est 3 ordres de grandeurs en dessous si on demande une meilleures unicité du résultat.

La question obligée est donc : pourquoi est-ce que cette fonctionne ne prend pas par défaut cette option, puisqu'elle a tous les avantages (meilleures résultats, plus rapide) ?

Types ENUM avec MySQL

Toujours en train de travailler avec MySQL, et encore pour un bon moment, voici une particularité du type enum :

Soit un champ field2 :

`field2` enum('0','1') NOT NULL default '0'

Soit une requête :

SELECT * FROM ... WHERE ... AND field2 = 1

Le résultat de cette requête est intéressant dans le sens où MySQL va sélectionner tous les tuples dont la valeur du champ field2 vaut '0'. Pourquoi cela ? Parce qu'en passant le 1 sous forme d'entier, MySQL va l'associer à la première valeur de l'énumération, '0' donc. Dans le même ordre d'idée WHERE ... AND field2 = 2 sélectionnera tous les tuples dont field2 vaut '1'.

La requête

SELECT * FROM ... WHERE ... AND field2 = '1'

fournira quant à elle la juste réponse. Attention donc avec les types des valeurs, surtout en PHP...

Mysql NT vs Unix : quand les systèmes de fichier font des différences

La question posée ici est la suivante : le nom des tables dans une base de données MySQL est-il sensible à la casse ou pas ?

La réponse dépend du système sur lequel le serveur tourne... Et cette différence vient même d'une manière plus intrinsèque du système de fichier sur lequel repose la base de données.

Explication :

Pour MySQL, une base de données est un répertoire du même nom dans lequel se trouvent des fichiers représentant les tables. Le nom des fichiers est naturellement identique aux tables, à l'extension prêt.

Pour savoir sur une base existe, MySQL va chercher si le répertoire correspondant existe. Du même principe pour accéder à un table il va ouvrir le fichier lié.

Sur un système de fichier Unix, ext3 ou reiserfs par exemple, un fichier base1/table1.MYI n'est pas le même que base1/tAbLe1.MYI, donc une requête "SELECT * FROM table1" ou "SELECT * FROM tAbLe1" ne produira pas le même résultat. Sur un système de fichier NTFS par contre, les chemins ci-dessus pointeront vers le même fichier, et donc les 2 requêtes précédents fonctionneront.

En conclusion, le nom des bases et tables MySQL sont sensibles à la casse sur un système Unix, et non sensible à la casse sur un système Windows.