L’idée de réaliser un URL-info (pour voir si je serais capable de faire un service aussi utile moi-même) me narguait depuis longtemps. En fait, il s’avère que ce n’est pas si difficile. De la même façon que les autres outils dont j’ai déjà expliqué les développements a posteriori, je vais dire les grandes lignes de ce qui me vient à l’esprit après avoir globalement terminé le développement de celui-ci. Avant toute chose, et malgré son évidente proximité avec l’idéal vers lequel je souhaitais aller, je ne pouvais pas l’appeler pareil (même si ç’eût été un hommage), donc j’ai trouvé un nom plutôt générique : Site Checker.   

La « home-page » du Site-Checker (une fois qu’on a entré une URL valide)

Plusieurs réflexions, donc :

J’ai eu des problèmes au début pour savoir quelle librairie de parsing utiliser (j’avais commencé par minidom, ce qui fut un fiasco, mais j’ai vite arrété dû au fait qu’une page web n’est pas forcément aussi strictement faite qu’un XML parfait), puis j’ai eu l’aide de mon collègue Ali S-O (Ali, je t’ai promis de te citer 😀 ) pour démarrer sur BeautifulSoup (que j’avais testé assez lamentablement il y a quelques mois), et je dois avouer que la librairie est sympa. Avec l’expérience qu’avait Ali, j’ai passé très rapidement les étapes de parsing, et quand il s’agit d’analyser une page web, autant dire que ça fait déjà une grosse partie du travail qui est abattue.

Pour ceux qui me demandent « pourquoi refaire ce qui existe déjà ? », je leur répondrais que je pense qu’il n’est pas très simple de faire mieux que l’existant si on n’est même pas capable de faire ce qui existe. Et pour être capable de faire ce qui existe, le mieux est de le faire soi-même.

J’admet au passage avoir toujours des problèmes d’encodage avec la balise Title (en utf-8 ou ISO), mais j’espère trouver comment régler ça, ce qui doit être possible vu que le gars de URL-info le fait.

Comme je le disais, je suis partit pour refaire au moins aussi bien que URL-info. Ça tombe bien, cet outil est également sur GAE, et en python, mais pour ma part je n’ai pas utilisé jQuery (j’ai préféré le JS home-made : cela m’entraine à en faire).

Au début j’avais mis la barre d’input de l’URL en bas, mais en fait je crois que le plus pratique est bien de la mettre en haut. C’est plus pratique, ça « résume » ce sur quoi porte l’analyse en dessous.

Je ne suis pas vraiment content de moi pour la preview des images : je n’arrive pas à faire un truc m’affichant des images ayant une max-height de 100px. Donc là, j’ai fait comme le gars de URL-info, à savoir height=100px (« forcé »), mais ça ne me convient pas : dès qu’une image est plus petite (hauteur plus faible que 100px), ça la grossit de façon assez peu jolie. A ce niveau là, il y aurait donc moyen de faire mieux.

Pas réussi non-plus à implémenter proprement les onglets. En soit, ce n’était pas mon but, mais j’aurais voulu pouvoir mettre un fond différent en fonction de l’onglet sur lequel on est, afin que l’utilisateur voit où il a cliqué et ce qui est enclenché. Pour l’instant, à la place, il y a un gros titre en <H2>, mais j’aimerais quand même un « onglet » ou un truc similaire.

Pour ce qui est des expand/collapse des listes, je l’ai fait en Javascript ‘à la main’, dans la mesure où je n’avais pas envie de mettre le fadding (que lui utilise via jQuery, et que je supporte pas). Je suis contre le fadding dans la mesure où, même si l’effet est sympa, il est rapidement lourd quand on utilise l’outil tous les jours.

Je ne suis pas sûr qu’il utilise la même fonction que moi pour le calcul du temps de téléchargement. Pour ma part, je fais juste un différentiel du temps pris avant et après l’appel de l’URL par la fonction urlfetch. Normalement, comme les deux sites fonctionnent sur GAE (et donc utilisent urlfetch, puisque c’est la seule librairie autorisée pour faire des requêtes HTTP), les temps devraient être exactement les même, mais bon…

De même, j’ai mis pas mal de temps à comprendre comment il calculait la taille en Kb du fichier. Je ne comprenais pas vraiment comment il pouvait faire, vu que GAE ne permet pas vraiment d’écrire des fichiers puis de voir la taille via os.environ.getSize()… En fait, et après quelques comparaisons, j’ai fini par comprendre qu’il prenait la longueur du fichier, il la divisait par 1024 et il tronquait le tout (pour obtenir un Int). En tout cas, en faisant comme ça, j’obtiens étonnamment les mêmes résultats que lui… 🙂

Pour parler du graphique des liens internes/externes/javascript : je ne sais pas exactement ce qu’il arrive à aller chercher pour les « liens Javascript » (d’après ce que j’ai vu, il prends au moins les popups), mais comme je ne suis en aucun cas sûr de fournir quelque chose de proche de la réalité en parlant de lien « javascript », je préfère ne pas du tout les mettre, et me limiter aux balises a href. De plus, c’est la première fois que j’utilisais Google Visualisations API, et je dois reconnaitre que la façon utilisée est extrêmement simple, même si c’est pas celle sur laquelle j’étais tombé via les tutoriels de débutant disponible chez Google, où il fallait importer pas mal de librairies JavaScript… Non, là, une simple URL d’image un peu trafiquée et on a l’image qu’on veut. Parfait 😀

Enfin, j’ai utilisé le DataStore de Google AppEngine (pour la première fois a ce niveau là, même si c’est juste une base), afin de voir ce qui a été vu les dernières fois et pour que Google référence un peu plus de choses. Ça devrait un peu plus aider au développement du site.

Edit : Quelques ajouts sur les réflexions.

• La meilleure des choses serait en fait de faire télécharger au visiteur un programme en javascript ayant les même fonctionnalités. Cela allègerait le serveur en traitements, MAIS cela ne mettrait pas les calculs de temps de chargement au même niveau (puisque la requête serait faite chez le client, et donc dépendrait de sa connexion internet) : l’avantage quand la requête est faite chez Google AppEngine, c’est qu’on bénéficie d’une connexion fibrée et égale sur la durée, donc on peut comparer les temps à partir d’une base correcte).
• J’avais au début une largeur de 1000px, mais j’ai réduis à 800px, cela me semble plus joli comme ça.
• Pour ce qui est de la rubrique « Infos », les informations collectées le sont grâce à la fonction urlparse (chez moi). Je pense que le gars de URLinfo utilise la même fonction, étant donné la proximité de nos résultats. A la différence que moi, je n’affiche que les champs non-vides, lui semble afficher tout.

Voilà. Maintenant quelques écrans.

Les headers (où on voit que AbriCoCotier tourne sur Nginx 🙂 )

Les images

Les liens, avec le collapse, et le graphe en Float à droite.

Comme d’habitude, si vous avez des feedbacks, repérez des bugs, n’hésitez pas !