Très rapidement, j’ai donc fait un outil permettant d’archiver (rassembler des fichiers dans un même fichier, qui conserver l’arborescence de ceux-ci), grâce à la librairie tarfile de python. La difficulté a été pour le fait que tous les tutoriels donnés sur internet considéraient que l’on pouvait écrire sur le disque (alors que là, non). Il a donc fallu jouer avec la création de fichiers stream (StringIO.StringIO), ce qui m’a permit de découvrir l’existence de la librairie cStringIO, qui, selon le site de Python, a les même fonctionnalités que StringIO, sauf qu’elle est plus rapide. Notez que j’ai été débloqué dans mes recherches via ce thread, ainsi que par celui-là.

J’ai eu beaucoup de mal à faire fonctionner le zip (en utilisant ZipFile) et le gzip, dans la mesure où gzip n’est pas un archiveur, mais seulement un compresseur. C’est à dire qu’on ne peut normalement lui donner qu’un seul fichier, donc il va compresser le contenu. Zip, lui, fait archiveur aussi, mais je n’ai jamais réussi à le faire fonctionner. Si vous avez déjà réussi à faire fonctionner du python+zip de plusieurs fichiers (quand il y en a un, ça va, c’est quand il y en a plusieurs qu’il y a des problèmes), je suis preneur de votre code.

Décompression

Par contre, en ce qui concerne la décompression des archives, je ne pouvais pas gérer celà sans passer par le DataStore, ou bien il aurait fallu que je passe par une API stockant les fichiers à l’extérieur. En gros, soit je stocke les fichiers dans le DataStore, auquel cas c’est peu fantastique (et encore, dans l’idéal, je pourrais les stocker dans MemCached : c’est une piste à creuser ! Je m’y atèle dès ce soir.), car le DataStore est assez sensible en terme de quantité de données stockées, et de « taille de fichier » à mettre dedans (1 Mo maximum). C’est donc la raison pour laquelle j’ai abandonné l’idée dans un premier temps.

Edit : Depuis hier, quand j’ai écris ces lignes, il y a eu quelques améliorations :

D’abord, le programme dé-gzippe parfaitement (en fait, je lui ai donné des tar.gz et des fichiers normaux pour tester, ça fonctionne pas mal). Enfin je pense. J’observe cependant des différences entre le nombre d’octets pour le tar créé à partir du tar.gz et le tar que j’aurais créé moi-même (la quantité d’octet n’est pas la même). Je soupçonne des différences entre les librairies utilisées, qui ne seraient pas les même entre la librairie tarfile et celle qu’utilise Gnome/Ubuntu.

Ensuite, le programme reconnait également quand le fichier porte l’extension .tar, auquel cas il liste les fichiers contenus dans le tar. Je n’arrive pas à gérer parfaitement le cas où il y aurais une arborescence de fichiers, car il faudrait reproduire cette arborescence en ligne (et ça, c’est violent), mais je parviens quand même à afficher la liste des fichiers (il faut tester pour voir, ou regarder sur le screenshot ci-dessous, où l’archive contenait entre-autres un dossier « AnaliZ » avec des fichiers dedans). En cliquant sur chaque fichier, j’enclenche le téléchargement direct de celui-ci. Bref, ça marche (même si ces petites subtilités ternissent la marche correcte du script).

Fichiers de grande taille dans Memcached et/ou le DataStore

Enfin, et c’est là que c’est beau, pour chaque fichier affiché, on peut le télécharger. Notez que, comme je n’enclenche pas le téléchargement directement après l’upload, il faut que je passe par un stockage interne des fichiers. Hors, ceux-ci peuvent souvent être amenés à faire plus de 1 Mo, c’est bien normal (quand on sait qu’on atteint facilement des taux de compression de 70% avec des fichiers texte, ça ne m’étonne pas du tout qu’un fichier compressé de 500ko puisse faire, après décompression, une taille de 1,6 Mo, par exemple), donc je dois gérer le stockage de fichier d’une taille supérieure à 1 Mo. Mais AppEngine limite à 1 Mo la taille des données stockées par instance dans MemCached ou le DataStore. J’ai donc découpé la string d’octets pour que chaque partie fasse au maximum 1 Mo et rentre dans une instance de MemCached. Oui, j’ai utilisé MemCached parce que je ne veux pas charger mon DataStore pour rien (les données décompressées n’ont pas pour but de rester longtemps disponibles, donc elles n’ont rien à faire dans le DataStore, et je les mets dans Memcached pour une durée d’environ une heure, ce qui laisse amplement le temps de les télécharger !).

Bon, voilà, donc au final, ça fonctionne correctement pour les .tar et les .gz, ce pour une taille de fichier entrant limitée par HTML (c’est à dire 2 Mo pour les navigateurs qui ne sont pas en HTML5, et davantage pour les autres… personnellement, j’ai testé avec 8Mo sur mon serveur en local, et celui-ci n’a pas bronché).

AbriCoCotier.fr, 2010. | Permalien | Ajoutez un commentaire ! | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, Python (et Django)

Explication du fonctionnement :

Très rapidement, voilà comment fonctionne le script que j’ai écris : a chaque URL demandée par le client (quand celle-ci est après le path /viamemcached ou /viadatastore), le script va chercher le contenu HTML de la page directement mémoire. Dans MemCached si l’URL demandée commence par /viamemcached ou dans la mémoire (pour AppEngine, il s’agit du dataStore) quand l’URL commence par /viadatastore).

Le principe est donc, quand l’URL demandée commence par /viadatastore, de simuler une recréation de page, à cause de la requête à la base de donnée. Et de tenter de reproduire le fonctionnement d’un cache en passant par MemCached.

Code :

Fichier main.py :

Le fichier ci-dessous répartit les requètes en 3 : la page d’admin (création de contenu), derrière /upload, la catégorie des pages nécessitant la génération de contenu via appel au datastore (via l’url /viadatatore), et enfin la catégorie des pages nécessitant juste la requête à Memcached.

import cgi
import firstPage
import userpage
import wsgiref
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

ROUTES = [
    ('/',firstPage.Home),
    ('/upload',userpage.Upload),
    ('/viadatastore/?([\w]*)/?', userpage.ContentUsage),
    ('/viamemcached/?([\w]*)/?', userpage.ContentCached),
 # other handlers here...
]

def main():
  application = webapp.WSGIApplication(ROUTES)
  wsgiref.handlers.CGIHandler().run(application)

if __name__ == "__main__":
  main()

Fichier firstpage.py :

Le fichier firstpage.py est « juste » le fichier de Home, répartissant entre les trois sections (au cas où vous voudriez reproduire l’application chez vous).

from google.appengine.ext import webapp

class Home(webapp.RequestHandler):
    def get(self):
        self.response.out.write("""<html>
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Test</title>
            </head>
            <body>
     <center>
        <h1>TEST</h1>
    </center>
    <br><br>
            <center><div style="text-align:left;margin:0% 30% 0% 30%;">
             <ul>
                <li>
                    <a href="/upload">Upload</a>
                </li>
                <li>
                    <a href="/viadatastore">viadatastore</a>
                </li>
                <li>
                    <a href="/viamemcached">viamemcached</a>
                </li>
             </ul>
             </div>
         </center>
     </body>
 </html>""")              

Fichier userpage.py :

Et enfin, le fichier userpage.py comprend les trois sections. Dans la classe Upload, on voit le formulaire d’envoi et le script d’enregistrement du contenu HTML dans le datastore. Dans la classe ContentUsage, on a la génération du contenu via DataStore, et dans ContentCached, celle via Memcached.

import cgi
import logging
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
from google.appengine.ext import db
from google.appengine.api import memcache

class pageUrlContent(db.Model):
    url = db.StringProperty(multiline=False)
    content = db.TextProperty()
    date = db.DateTimeProperty(auto_now_add=True)

def add_content_in_base(url,content):
    pageUrlContent = pageUrlContent()
    pageUrlContent.url = cgi.escape(url)
    pageUrlContent.content = db.Text(content)
    pageUrlContent.put()  

def render_list_previous_queries(url):
    listurls = pageUrlContent.all().filter("url =", url)
    return listurls

def fetch_content_in_base(url):
    final_content = ""
    contents = render_list_previous_queries(url)
    if contents:
        for cont in contents:
            final_content = cont.content
    return final_content

def fetch_content_in_cache(url):
    thiscontent = memcache.get(url)
    if thiscontent:
        return thiscontent
    else:
        content = fetch_content_in_base(url)
        if not memcache.set(url, content):
            logging.error("Memcache *set* failed in fetch_content_in_cache(url)>else>ifnot.")
        return content  

class Upload(webapp.RequestHandler):
    def get(self):
        self.response.out.write("""
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Content Upload</title>
</head>
<body>
<center>
<form action="/upload" enctype="multipart/form-data" method="post">
  <div><input type="text" name="url"></div>
  <div><textarea COLS=30 ROWS=30 name="content"></textarea></div>
  <div><input type="submit" value="Send IT"></div>
</form>
</center>
</body>
</html>
    """)
    def post(self):
        url = self.request.get("url")
        content = self.request.get("content")
        add_content_in_base(url,content)
        self.response.out.write("""<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Content Upload</title>
</head>
<body>
<center>
OK
</center>
</body>
</html>
    """)  

class ContentUsage(webapp.RequestHandler):
    # part of ImageHandler class
    def get(self,id):
        content = fetch_content_in_base(id)
        self.response.out.write(content)    

class ContentCached(webapp.RequestHandler):
    # part of ImageHandler class
    def get(self,id):
        content = fetch_content_in_cache(id)
        self.response.out.write(content)

Performances :

Les logs de AppEngine sont de ce type :

08-09 06:46AM 39.408 /viamemcached/loremipsum 200 22ms 19cpu_ms 7kb Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.22 Safari/534.3,gzip(gfe)
149.6.164.150 – - [09/Aug/2010:06:46:39 -0700] « GET /viamemcached/loremipsum HTTP/1.1″ 200 7725 – « Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.22 Safari/534.3,gzip(gfe) » « abricocotierfrtests.appspot.com » ms=23 cpu_ms=19 api_cpu_ms=0 cpm_usd=0.001455

D’après ce que j’ai compris, on peut extraire 4 valeurs : ms=23 cpu_ms=19 api_cpu_ms=0 cpm_usd=0.001455. Je n’ai pas bien compris à quoi correspondaient tous ces temps, mais ce dont je suis sûr, c’est que le api_cpu_ms correspond au temps de l’API du DataStore.

En effet, j’ai fait une vingtaine de tests (enfin 20 reload par catégorie), et je mes ai mis dans un tableau, puis j’en ai fait des graphiques :

Le tableau de données :

Millisecondes :

CPU Millisecondes :

API CPU Millisecondes :

CPU USD :

Conclusion

De ce que l’on peut constater, effectivement l’API_CPU_MS est à zéro après le premier appel sur Memcached, ce qui correspond bien à la premier mise en cache (lors du premier appel), puis c’est le cache qui prend le relais, et le datastore n’est plus appelé (et on remarque que les appels au datastore font tous 22ms). Pour le reste, c’est plus compliqué. Il semble que, sur le global, MemCached soit plus rapide (légèrement), mais ce n’est pas une règle absolue, et on voit que selon les appels, les temps varient, si bien que certains appels via DataStore se révèlent plus rapides que certains via MemCached.

D’une manière générale, Google imposant de respecter les quotas (ce que je trouve louable), cela impose à coder relativement « économiquement », c’est à dire avec l’idée qu’il faut utiliser Memcached aussi souvent que possible. Je rajoute que pour mon test, l’appel au DataStore était relativement simple, pas de SELECT *, ce qui peut expliquer la proximité des résultats avec MemCached. Cependant, je pense que dans un cas plus proche de la réalité, où la génération d’une page nécessite plusieurs appels au DataStore, la différence devient plus évidente.

Je n’ai pas non plus testé via l’utilisation de templates Django, mais je doute que celà accélère grand chose au traitement de la page, et donc encore une fois, cela devrait augmenter la différence entre une page donc l’intégralité du code se trouve en MemCached, et une autre pour laquelle il faut réaliser une certaine quantité d’opération de génération.

AbriCoCotier.fr, 2010. | Permalien | 1 commentaire | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, Python (et Django), Wordpress

Soyons clair, ce n’est pas ma première tentative avec cette application. J’avais déjà tenté une première approche il y a environ deux semaines. Approche qui s’était révélée infructueuse, devant la difficulté pour trouver des ressources en la matière (du coup, ça tombe bien : c’est moi qui vais les fournir, cette fois). En effet, sur internet, on trouve majoritairement deux librairies pour manipuler des PDF en python : PyPDF et ReportLab. ReportLab, dans sa version gratuite, permet de créer des PDF, mais pas vraiment de les lire ni de les fusionner. Cette fonctionnalité semble être offerte par un addon payant, PageCatcher.

A l’inverse, PyPDF propose une solution très rapidement maîtrisable pour lire des pages d’un PDF, les concaténer, et donc faire des opérations de fusion ou d’extraction de PDF de façon très rapide. Sauf… que pour AppEngine, il n’existait aucune ressource indiquant comment on pouvait « écrire » le fichier de sortie sur la sortie HTTP, soit donc pour le client. Je rappelle que la plateforme AppEngine ne permet pas réellement d’écrire et de créer des fichiers, et n’autorise cela que via des Blobs dans le DataStore (ou dans le BlobStore, si on a activé le billing, ce qui n’est pas mon cas). A l’inverse, il existait pas mal de ressources sur le net pour utiliser ReportLab avec AppEngine. Gloups, j’étais tiraillé entre deux librairies.

Après pas mal d’essais infructueux, j’ai eu, par chance, la possibilité d’obtenir enfin la création de PDF (avec PyPDF, et donc je n’utilise pas du tout ReportLab), puis celle de la lecture correcte de PDF venant des fichiers envoyés à la page (et non de fichiers lus en local, ce qui est différent). Et du coup, de fil en aiguille, j’ai fait l’outil qui est disponible là.

Plusieurs choses :

Le premier outil permet de fusionner des PDF. Le titre du document est réglé pour être celui du premier document dans la liste. Le serveur ne traite pas les documents n’ayant pas l’extension .pdf, et fait des try/catch sur la concaténation d’un PDF au fichier de sortie. En gros : si sur le lot, un PDF n’est pas lisible, le programme l’ignore, et continue sa route avec le reste.

Le deuxième outil permet d’enlever certaines pages à un PDF. Sachant qu’il faut impérativement lister correctement les pages entre virgules. C’est simple, le programme prend le fichier en entrée, ainsi que la liste des chiffres représentant les pages à ne pas mettre. Pour chaque page, le programme demande si le numéro de cette page fait partie de la liste des pages à ne pas mettre, et si oui, il ne l’ajoute pas au fichier de sortie.

Le troisième outil permet d’extraire une partie de PDF d’un PDF d’entrée. En gros, si, sur un PDF, vous ne voulez conserver qu’une partie, il suffit d’indiquer la page de début et la page de fin de la partie de document que vous voulez conserver.

Voilà ! C’est tout simple. Si vous avez des problèmes pour l’utilisation, n’hésitez pas à venir le dire ici, je tenterai ensuite de résoudre ce bug.

Pour le reste, voici le code python permettant de manipuler un PDF acquis en variable POST et de le renvoyer en réponse au client. C’est, en allégé, le code que j’utilise pour le premier programme. Voilà la partie du code qui est importante :

from pyPdf import PdfFileWriter, PdfFileReader

pdf_filename = ''
output = PdfFileWriter()
pdf_file = self.request.POST.get("file",None)
pdf_filename = cgi.escape(pdf_file.filename)
pdf_content = PdfFileReader(pdf_file.file)
numpages = pdf_content.getNumPages()
for i in range(0,numpages):
    output.addPage(pdf_content.getPage(i))
self.response.headers['Content-Type'] = 'application/pdf'
self.response.headers['Content-Disposition'] = 'pdf; filename='+pdf_filename
output.write(self.response.out)

AbriCoCotier.fr, 2010. | Permalien | 10 commentaires | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, Google, Programmation, Python (et Django)

L’outil :

Le principe est de pouvoir envoyer des mails personnalisés.
Imaginons que vous ayez plusieurs personnes à qui vous souhaitez envoyer un même email, mais avec des parties personnalisées à chaque personne. Il vous faut donc un tableau à double entrées avec, pour chaque destinataire, des champs personnalisés.

Ensuite, dans le titre du mail et dans le corps de celui-ci, des balises {FIELD} indiquent où seront remplacées les informations pour chaque utilisateur, et ce bien sûr avant l’envoi de chaque mail.

Notez que c’est le principe de toute application de publipostage inclue dans n’importe quel CRM ou outil de listes de diffusion, permettant de personnaliser des mails envoyés en masse.

Là, dans mon application, on peut envoyer le mail personnalisé à un maximum de 10 personnes(en cliquant sur « Add To: »), et on peut également ajouter des pièces jointes (en cliquant sur « More » ; 3 pièces jointes maximum par mail). Pour supprimer un To: ou une pièce jointe, faite simplement « delete To: » ou « less », et la ligne sera supprimée.

J’ai mis des boutons autour du champs Subject et du champs Mail Content pour qu’il soit facile d’ajouter les références au sein du texte.

Par contre, je ne suis pas certain que l’utilisation d’un tel script soit facile pour tout le monde. Pour tout dire, je l’ai fait tester à une personne hier soir (qui n’avait jamais utilisé de CRM), et elle a eu du mal à comprendre le principe de ce script, même si, une fois que je lui ai expliqué l’idée, ça a été beaucoup mieux.

Les cas d’utilisation de ce script sont multiples : mails de faire part, de candidature pour un emploi (avec envoi de CV et/ou lettre de motivation en pièce jointe), de proposition de partenariat commercial, bref, dès qu’il y a un grand nombre de personnes à contacter avec une minorité de champs à adapter, ce script peu s’avérer utile. Evidemment, pour une utilisation plus poussée, je recommende l’utilisation d’un vrai CRM (par exemple VTigerCRM).

Exemple :

Page de confirmation :

Les subtilités de l’application :

Les mails sont envoyés au format texte. Donc pas de possibilité de mettre du HTML. Si je trouve un moyen de le faire, je le ferai. J’ai tenté avec TinyMCE Editor, mais le problème était que TinyMCE fonctionne avec une iframe, et donc je ne pouvais plus mettre de bouton {FIELD} pour placer les champs à modifier. J’ai bien tenté de créer un bouton custom avec TinyMCE, mais ça n’a pas fonctionné. Si vous avez des idées, je prends.

AppEngine a pas mal de limitations sur l’envoi de mail, notamment sur la bande passante sortante en terme de pièces jointes (limitée à 100Mo par 24h). Donc evitez d’abuser sur celles-ci, sinon l’application va tomber toute seule.

A cause d’AppEngine également, l’adresse de départ des mails (l’expéditeur) ne peut être qu’une adresse Gmail (ou Google Apps Edit : j’ai essayé avec le mien, en vain.), comme expliqué là :

For security purposes, the sender address of a message must be the email address of an administrator for the application,

Evidemment, le nombre de destinataires max pour le formulaire est un choix personnel. J’ai fixé à 10 la limite, parce que ça me semble être un bon compromis. Pareil pour les pièces jointes, la limite est à 3, mais je n’ai pas de quoi savoir s’il y a un besoin d’avoir davantage de champs à pièce jointe. Pareil pour les champs, j’ai limité à 3, mais je pourrais très bien augmenter.

Comme d’habitude, si vous êtes confrontés à des problèmes d’utilisation, n’hésitez pas à venir en discuter ici. Si vous avez des requêtes (vous voulez davantage de pièces jointes, davantage de destinataires, davantage de champs personnalisables ?), dites-le aussi en commentaire.

AbriCoCotier.fr, 2010. | Permalien | 6 commentaires | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, Google, Programmation, Python (et Django)

(du coup, pas grand chose à dire sur cette application, donc ce billet va essentiellement servir de page de feedbacks)

Ah si, 2-3 petites choses à dire quand même.

• Le Base64 s’obtient très simplement avec python, comme suit (après avoir importé la librairie Base64):
  

  encoded_content = base64.b64encode(content)

• Le gzip est calculé via la libraire python zlib, et via la fonction compress. Après il me suffit de faire un len() dessus pour connaitre le nombre d’octets. La ligne de code est donc :
  

  gzip_encoded_content_length = len(zlib.compress(encoded_content))

• Le fichier uploadé se lit comme suis sur AppEngine (sans passer par le datastore : je ne stocke rien du tout) :
  

  query_file = cgi.escape(self.request.POST.get(‘file’).file.read())

Par contre, je discutais tout à l’heure avec Rangzen Kermit (qui s’avère être camarade de promo ), et il me disait que ce qui serait bien, ce serait de faire un outil qui puisse s’adapter au fait que IE5/6/7 ne supportent pas le Base64. Pour le coup, il m’a donné le lien vers un billet très utile sur le sujet : Quick Tip: How to Target IE6, IE7, and IE8 Uniquely with 4 Characters.

De mon côté, je pense que ce qui serait bien, c’est de mettre un fichier CSS en entrée (en uploadant ou en mettant l’URL) et que l’utilitaire sur AppEngine parse le CSS en trouvant toutes les références internes à des images (par exemple les background: url(image/toto.png);), et irait remplacer ces références par le code Base64 créé à partir de l’image (si celle-ci est correctement récupérée). (Edit : Kermit m’a aussi formulé l’idée)

Honnêtement, je pense que c’est faisable, mais déjà beaucoup plus violent.

Parce que, autant un script comme celui-ci serait bien utile, autant l’idée de Kermit est assez importante, et tant qu’à faire, il serait aussi bien de mettre dans le même temps la référence pour que les « vieux » navigateurs continuent à voir la ressource, une fois qu’on a pu encoder celle-ci en Base64.

Dans un premier temps, je ne crois pas que je pourrais faire assez rapidement un outil parsant le CSS et relevant toutes les occurrences de url(), allant voir si l’URL contient http://, etc, mais ça n’irait pas beaucoup plus loin…

AbriCoCotier.fr, 2010. | Permalien | 12 commentaires | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, Google, Programmation, Python (et Django)

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 !

AbriCoCotier.fr, 2010. | Permalien | 13 commentaires | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, JavaScript, Programmation, Python (et Django)

D’abord le pourquoi : Pourquoi continuer à s’entêter à vouloir faire davantage de traitements par unité de temps sur des même machines, alors que le coût du matériel baisse sans cesse, et qu’il suffirait d’investir (peu) dans des serveurs plus puissants ?

La réponse est simple : j’ai eu la preuve sous mes yeux que c’était possible, et que, avec un peu de technique/connaissance/travail, on pouvait faire des choses incroyablement rapides, même avec des ordinateurs aujourd’hui considérés comme « vieux ». Rien que parce que les MegaHertz des processeurs constituent des millions de calculs par secondes, et donc que cette fréquence peut suffire, si elle est bien utilisée, à servir un nombre déjà énorme de pages sur un site.

Le problème est donc de coder dans un langage assez rapide (car assez proche du langage machine ou assez compilé) pour rapprocher les traitements à exécuter des fonctions de base du processeur. C’est possible avec des langages tels que le python (quand il est compilé), ou encore plus simplement avec Java, mais évidemment, cela freine toute simplicité de modification du code à la volée (car une compilation est nécessaire), comme le permet le PHP (qui y perd donc sa rapidité, car il est « relu » à chaque fois) (même si lui aussi peut être compilé/mis en cache, par exemple avec PHP Accelerator).

Bref, au final, je me demandais si un CMS « évolué » aurait un temps d’exécution meilleur en étant codé avec un autre langage (en l’occurrence, pour Plone, c’est Python). Dans « évolué », j’entends : « en ayant une perspective de fonctionnalités équivalentes » (c’est à dire avec un système d’extension). Le mieux pour faire un tel comparatif serait de le faire serait de le faire sur un même serveur (disons Apache + mod_python) et avec une même BDD (même serveur pour permettre d’être facilement interchangeable, et de ne comparer les performances propres que d’un seul maillon de la chaine). Allons à l’essentiel : à part le billet suivant « Notes on migrating this blog from WordPress to Plone« , ainsi que le tutoriel sur le site de Plone.org, je n’ai pas trouvé grand chose traitant de Plone et Apache/MySQL, étant donné que celui-ci étant bien plus conseillé d’être mis dans un environnement Zope+Plone+Blob. Le billet le plus intéressant sur les performances de Ploneque j’ai pu trouver  face à WordPress est celui-là : « Plone 4, un CMS plus rapide que WordPress« , qui appelle ce site.

On voit que Plone a des performances approchant le double de celles de WordPress. Sur le site de Plone, le graphique est un peu différent (performances trois fois supérieures à celles de WordPress) :

Ailleurs, sur 01net, un tableau comparatif de plusieurs CMS n’est pas très favorable aux performances de Plone (3/5 en « Robustesse et Performance »), à l’inverse de de eXo Platform, en Java, qui s’en sort beaucoup mieux (4,5/5), et en dessous de Typo3 et Drupal, tous deux (3,5/5) en PHP.

Alors, que faire ? Pour résumer, il ne semble pas que Plone s’en sorte beaucoup mieux que ce que j’aurais espéré par rapport à WordPress. Changer de CMS python alors ? Si je regarde chez DjangoCMS, PyLucid, ou Skeletonz, je ne suis pas sûr de trouver des fonctionnalités équivalentes à ce qu’il y a sur WordPress (grosse communauté, et grosse base de plugins/extensions). La solution pourrait donc venir d’ailleurs : je vois venir l’avènement progressif des CMS Ruby/Rails avec Phusion Passenger/Mod_Rails qui fonctionne avec Nginx, et donc les performances sont tout à fait bluffantes. Reste bien sûr à aligner les fonctionnalités, mais il semble que les projets de CMS en Ruby ne manquent pas, donc il ne me reste plus qu’à aller voir de ce côté là pour trouver mon bonheur

AbriCoCotier.fr, 2010. | Permalien | 9 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Python (et Django), Wordpress

J’ai donc réfléchis au début à faire quelque chose juste en HTTP/CSS, mais je dois avouer que j’ai vraiment eu du mal. Je voulais depuis le début baser le tout sur un compte AppEngine, donc il fallait que ce que je développe soit compatible avec leur plateforme, ce qui n’a pas été le cas pour les premiers essais que j’ai fait avec leur librairie Analytics (que j’ai testé au début) présente au sein de la Gdata Python. Bref (en fait, leur librairie Gdata Python / Analytics fonctionne très bien, mais elle ne fonctionne par sur le dev_appserver de AppEngine). Entre temps, comme je l’expliquais plus haut, j’ai changé de smartphone, et le nouveau s’est révélé tout à fait capable de supporter le Javascript, donc je suis passé sur le client Javascript fournit sur la doc de Google.

Comme d’habitude, je le répète, loin de moi l’idée de me vanter ici : je ne fais ce genre d’application que pour me prouver que je suis capable de les faire, ayant l’impression perpétuelle d’être mauvais en programmation. Et puis au passage, je mets le service à dispo pour tout le monde, parce que ça ne coûte rien et que ça peut servir.

Sur le coup, le but était multiple : au début, il fallait que je créée un client Analytics en HTTP/CSS/JS qui fournirait les infos que je vais voir le plus souvent sur Analytics (les pages les plus vues de la journée en cours, ainsi que le nombre de visiteurs uniques/pages vues de la journée en cours). Par la suite, j’ai eu l’opportunité de rajouter des graphiques dessus, ce qui m’a permit de « valider » une promesse que je m’étais faite au début de l’année.

Donc en terme de technologies utilisées, il y a une base de pages simples en python sur AppEngine (ce qui permet d’avoir un coût d’hébergement égal à zéro), avec une base de Javascript via la doc pour JavaScript donnée par Google, avec une surcouche de JavaScript via la librairie JSCharts qui créée des graphiques via des balises <canvas> (c’est donc du HTML5, mais mon smartphone supporte ça très bien). J’ai utilisé les graphiques en bâtons et en courbes.

Les écrans de l’application

Je ne vais pas y aller par quatre chemins. D’abord et avant tout, plutôt qu’un long discours, l’application est disponible ici.

Pour le reste, l’application fonctionne comme suis : (J’ai gardé l’interface de base du client Javascript fourni par Google, et j’ai rajouté/compilé/adapté quelques fonctionnalités.)

Après vous être loggué chez Google (l’application ne retient aucun mot de passe, tout se passe chez vous), vous arrivez sur un écran. Cliquez sur le bouton « Get Account Data », et vous obtiendrez laliste des comptes que vous avez chez Analytics. A droite de chaque compte, un bouton « Choose » qui met dans le champ le code correspondant au compte sélectionné.

Ne vous reste plus ensuite qu’à cliquer sur le bouton « Get PageWiewed » pour obtenir la liste des pages les plus vues sur la journée (par contre, je n’ai pas encore réussi à résoudre le problème d’encodage) :

Ou bien vous pouvez également cliquer sur le bouton « Get Visits » pour obtenir la liste des visites uniques, nombre de pages vues et ratio sur les 14 derniers jours. Les données affichées sont exactement les mêmes que celles que vous aurez en allant sur votre compte Analytics (si si, vérifiez, si vous ne le croyez pas).

Je compte améliorer le client, histoire de rajouter les fonctionnalités de listing des mots clefs/sites référents sur la dernière journée, mais aussi  des visiteurs (navigateurs, système d’exploitation, etc) sur les 14 derniers jours, sur les modèles des pages existants déjà.

Pour ce qui est du support des différents navigateurs, je sais que cela fonctionne sur Firefox 3.6.x, Chrome 5 et 6, et même Internet Explorer 7 (pour ceux qui seraient dessus…) (oui, ce sont les navigateurs testés ; je n’ai pas les autres sous la main).

Vous remarquerez également que le compte AbriCoCotier Application contient :

• Un outil de Whois (qui passe par l’API de WhoisXMLAPI en HTTP car AppEngine n’autorise que ce port là)
• Un outil pour vous donner votre IP
• Un compteur de mots
• Je compte rajouter d’autres applications, me permettant d’aller me frotter à d’autres API de Google, ou autres.

Je suis bien sûr au courant que ces petits outils existent déjà, mais ils font partie de ma volonté de « les avoir fait moi-même ».

Si vous avez un commentaire là dessus, ou souhaitez rapporter un bug, une faute d’orthographe, n’hésitez pas, les commentaires sont faits pour ça.

AbriCoCotier.fr, 2010. | Permalien | 3 commentaires | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, Google, JavaScript, Programmation, Python (et Django)

Le problème, c’est que pour toutes les petites images à charger dans une page, beaucoup son petites, mais nécessitent chacune une requête au serveur qui les fournit. Or, très souvent, c’est la connexion et le temps de latence au serveur qui prennent davantage de temps que le téléchargement lui-même ! C’est la raison pour laquelle on utilise le CSS pour créer la mise en forme, car le CSS permet de « générer des images » : plutôt que de télécharger l’image toute faite, on délègue sa création à l’ordinateur de l’utilisateur. Par exemple : plutôt que de faire télécharger un background de page de 2000×1500 pixels de couleur rouge unie qui en PNG prendrait 44ko (j’ai fait le test), on peut le remplacer par une ligne CSS disant :

div.maclasse{
     position:absolute;
     left:0px;
     top:0px;
     width:2000px;
     height:1500px;
     background:RED;
}

..ce qui fait moins d’1 ko : l’ordinateur va générer tout seul l’image.

Pourquoi, donc, ne pas tenter de supprimer le téléchargement de ces images en tentant de les générer à partir du fichier CSS ?

C’est ce que j’ai fait via un script Python qui prend en entrée un fichier PNG et qui fournit en sortie un fichier HTML et un CSS permettant tous deux d’afficher l’image, en la générant pixel par pixel.

Comment ça marche ?

Le programme prend un fichier PNG, en extrait les données. Cela donne (je simplifie) un grand tableau à double entrée avec, pour chaque case, la couleur de la case (ou du pixel). Après, il suffit d’afficher ce pixel dans la page HTML en lui donnant comme couleur de fond la couleur qu’il avait dans l’image. Le programme reconstruit donc l’image à l’aide du CSS.

Attention, il n’est nullement question d’alléger les fichiers pour l’instant : par exemple, la compression du logo Google pris en PNG (qui faisait 12ko) a donné un HTML de 851ko et un CSS de 2650ko. Donc le script n’optimise pas en terme de taille, il optimise en terme de nombre de fichiers.

Plusieurs passes d’optimisation

Comme je vous l’ai dit plus haut, le script prend chaque pixel de l’image source, et le transforme en une ligne CSS, fournissant le background pour un pixel, et la position à laquelle afficher le pixel. Bien sûr, je récupère proprement la position du pixel dans l’image source (ou je la calcule, plus précisément), et j’adapte la position à laquelle je veux afficher le pixel dans la page cible.

Par exemple pour le pixel tout en haut à gauche de l’image :

div.maclasse1{
position:absolute;
     left:0px;
     top:0px;
     width:1px;
     height:1px;
     background:RED;
}

Explication : le pixel est décalé de 0 pixel de la gauche de l’écran (left:0px), de 0 pixel du haut de l’écran (top:0px), et il a une largeur de 1 pixel (width:1px) et une hauteur de 1 pixel (height:1px).

Mais cette technique n’est pas du tout optimisée : elle créée autant de lignes CSS (et de ligne HTML) que de pixels dans l’image. Donc pour une image source de 200×300 pixels, vous vous retrouvez avec des fichiers HTML et CSS de 60000 lignes chacun. Et ce, même si l’image n’avais qu’une seule couleur.

L’idée des passes d’optimisation (que l’on retrouve souvent dans les algorithmes de compression), c’est de revoir plusieurs fois la sortie de l’image, et donc, quand on a des informations similaires, de les regrouper. Par exemple : si j’ai trois pixels de la même couleur les uns à côté des autres, plutôt que d’écrire trois lignes CSS (une par pixel) :

div.maclasse1{
     position:absolute;
     left:0px;
     top:0px;
     width:1px;
     height:1px;
     background:RED;
}
div.maclasse2{
     position:absolute;
     left:1px;
     top:0px;
     width:1px;
     height:1px;
          background:RED;
}
div.maclasse3{
     position:absolute;
     left:2px;
     top:0px;
     width:1px;
     height:1px;
     background:RED;
}

…pourquoi ne pas écrire une seule ligne disant qu’il faut générer les 3 à la suite ?

div.maclasse1{
     position:absolute;
     left:0px;
     top:0px;
     width:3px;
     height:1px;
     background:RED;
}

Comme vous pouvez le voir, dans celui-là, je dis de placer un background de largeur 3 pixels (width:3px). Le résultat affiché est exactement le même dans les deux cas, mais celui en bas prend trois fois moins de places en terme d’information.

L’idéal serait donc d’optimiser les fichiers de sortie afin de rassembler où c’est possible les directives, ce pour gagner de la place (et ne pas avoir des fichiers en sortie avec des milliers de lignes). Le problème, c’est que l’image source nous donne des informations pixel par pixel : il faut donc passer plusieurs fois pour détecter les pixels similaires et les associer entre eux.

Autant de passes que de dimensions

Attention, ici je parle de Run-Length Encoding (codage par plage) : je vous conseille d’aller lire la (très courte) fiche Wikipédia sur le sujet.

Plus exactement, le script fait 2 passes : dans la première, il transforme ce qu’il reçoit (des triplets RGB) en couleurs HTML (hexadécimales), tout en détectant les pixels qui se suivent et sont de la même couleur (sur une même ligne) : il les associe. Pour le PNG de logo Google, on obtient un HTML de 256ko et un CSS de 789ko.

Cette première passe ne suffit pas : en effet, pour une image de 200×300 pixels de la même couleur, il y aurait quand même 300 lignes pour dire de mettre la même couleur sur toute la ligne. Pourquoi pas ne mettre qu’une seule ligne pour dire de ne mettre la même couleur sur toute la ligne, mais également pour toutes les lignes ? De 300 lignes, on passerait à une seule. C’est le but de la deuxième passe.

(si vous voulez, la première passe fait une optimisation par ligne, la seconde rajoute les colonnes)

Évolutions potentielles

L’avantage du PNG, c’est qu’il gère la transparence. Malheureusement, de ce que j’ai vu sur la librairie que j’utilise (PyPNG), cet aspect semble être fournit, mais je n’ai pas pu le constater sur le fichier que j’ai testé (un bête fichier avec de la transparence, généré avec Paint.NET), et mon script a alors planté lamentablement. Je vous recommande donc de ré-enregistrer vos fichiers avec le Paint de Windows pour être sûr que ça fonctionne (en tout cas, c’est ce que j’ai fait pour chaque fichier PNG de test, et ça fonctionnait).

Par ailleurs, grâce au CSS3, il serait possible (mais très violent) de détecter les dégradés et de les reproduire avec le CSS. Ce serait un gros potentiel d’optimisation, mais j’ai du mal à croire à la faisabilité de la chose.

Enfin, je peux également compresser encore plus en définissant une couleur de base (ce que j’appelle la 3ième passe d’optimisation sur le graphique ci-dessus). Pour cela, je n’ai qu’à prendre la couleur qui revient le plus souvent, et à décider quelle est la couleur de fond. Puis, je saute les passages où c’est cette couleur qui est demandée. Sans l’utilisation de cette technique, j’obtiens, après les deux passes, le fichier HTML a 203ko et le CSS à 631ko pour un logo Google en PNG d’une taille de 12ko. Avec cette technique, j’obtiens une image identique, mais un HTML de taille 189ko et un CSS de 585ko.

Le petit plus rigolo

Un truc rapide et amusant : amusez-vous à grossir la taille du texte, vous verrez que le logo grossi, bien sûr, mais de surcroît vous verrez de quelle façon il espace progressivement les pixels (testé sur Chrome) :

Le code est téléchargeable là.

Pour tester chez vous sur le logo Google, c’est là (l’image originale est là).

Au passage, un programme facile d’utilisation existe déjà pour les jpeg, mais il n’est qu’en noir et blanc, et ne fonctionne pas pixel par pixel : jpeg2css.

AbriCoCotier.fr, 2010. | Permalien | 9 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Programmation, Python (et Django)

J’ai testé ça sur des listes différentes, d’environ 9000 éléments chacune, ce qui me permet d’avoir un temps à peu près regardable, mais pas tant que ça (le temps total reste quand même infiniment petit à mes yeux), comme on va pouvoir le voir.

J’ai mis le code de test des trois fonctions en dessous, pour ceux que ça intéresse.

Pour le reste, voici le log d’exécution de ces fonctions (j’ai viré les mentions inutiles). Notez que Group1 est extrait d’un outil, et que Group2 est extrait de Google Groups. Les vérification à l’issue des trois tests servent à faire une diff entre les résultats, afin de montrer (si diff = 0) que les fonctions renvoient exactement les même listes.

• 2010-03-15 12:41:51,358 – Start.
• 2010-03-15 12:41:51,375 – Nombre total de groupes dans Group1 : 9173
• 2010-03-15 12:41:51,375 – Nombre total de groupes dans Google Groups (Group2) : 9118
• 2010-03-15 12:41:51,391 – Making difference between Group2 & Group1 :
  references found in Group1 but that don’t exist in Google Groups
• 2010-03-15 12:41:51,391 – Starting Difference with SET : 2010-03-15 12:41:51.391000
• 2010-03-15 12:41:51,405 – Finishing Difference with SET : 2010-03-15 12:41:51.406000
• 2010-03-15 12:41:51,405 – SET time : 0:00:00.015000
• 2010-03-15 12:41:51,405 – Starting Difference with FROZENSET : 2010-03-15
  12:41:51.406000
• 2010-03-15 12:41:51,405 – Finishing Difference with FROZENSET : 2010-03-15
  12:41:51.406000
• 2010-03-15 12:41:51,405 – FROZENSET time : 0:00:00
• 2010-03-15 12:41:51,405 – Starting Difference with FILTER : 2010-03-15
  12:41:51.406000
• 2010-03-15 12:41:53,530 – Finishing Difference with FILTER : 2010-03-15
  12:41:53.531000
• 2010-03-15 12:41:53,530 – FILTER time : 0:00:02.125000
• 2010-03-15 12:41:53,530 – Verification. Difference entre meth1 et meth2 : 0 | et
  difference entre meth2 et meth3 : 0
• 2010-03-15 12:41:53,530 – Making difference between Group1 & Group2 :
  references found in Google Groups but that don’t exist in Group1
• 2010-03-15 12:41:53,530 – Starting Difference with SET : 2010-03-15 12:41:53.531000
• 2010-03-15 12:41:53,546 – Finishing Difference with SET : 2010-03-15 12:41:53.547000
• 2010-03-15 12:41:53,546 – SET time : 0:00:00.016000
• 2010-03-15 12:41:53,546 – Starting Difference with FROZENSET : 2010-03-15
  12:41:53.547000
• 2010-03-15 12:41:53,546 – Finishing Difference with FROZENSET : 2010-03-15
  12:41:53.547000
• 2010-03-15 12:41:53,546 – FROZENSET time : 0:00:00
• 2010-03-15 12:41:53,546 – Starting Difference with FILTER : 2010-03-15
  12:41:53.547000
• 2010-03-15 12:41:55,687 – Finishing Difference with FILTER : 2010-03-15
  12:41:55.688000
• 2010-03-15 12:41:55,687 – FILTER time : 0:00:02.141000
• 2010-03-15 12:41:55,687 – Verification. Difference entre meth1 et meth2 : 0 | et
  difference entre meth2 et meth3 : 0
• 2010-03-15 12:41:55,703 – Making intersection between Group2 & Group1
• 2010-03-15 12:41:55,703 – Starting Intersection with SET : 2010-03-15
  12:41:55.703000
• 2010-03-15 12:41:55,703 – Finishing Intersection with SET : 2010-03-15
  12:41:55.703000
• 2010-03-15 12:41:55,703 – SET time : 0:00:00
• 2010-03-15 12:41:55,719 – Starting Intersection with FROZENSET : 2010-03-15
  12:41:55.703000
• 2010-03-15 12:41:55,719 – Finishing Intersection with FROZENSET : 2010-03-15
  12:41:55.719000
• 2010-03-15 12:41:55,719 – FROZENSET time : 0:00:00.016000
• 2010-03-15 12:41:55,719 – Starting Intersection with FILTER : 2010-03-15
  12:41:55.719000
• 2010-03-15 12:41:57,875 – Finishing Intersection with FILTER : 2010-03-15
  12:41:57.875000
• 2010-03-15 12:41:57,875 – FILTER time : 0:00:02.156000
• 2010-03-15 12:41:57,875 – Verification. Difference entre meth1 et meth2 : 0 | et
  difference entre meth2 et meth3 : 0
• 2010-03-15 12:41:57,905 – Making the intersection between Group1 & Group2
• 2010-03-15 12:41:57,905 – Starting Intersection with SET : 2010-03-15
  12:41:57.906000
• 2010-03-15 12:41:57,921 – Finishing Intersection with SET : 2010-03-15
  12:41:57.922000
• 2010-03-15 12:41:57,921 – SET time : 0:00:00.016000
• 2010-03-15 12:41:57,921 – Starting Intersection with FROZENSET : 2010-03-15
  12:41:57.922000
• 2010-03-15 12:41:57,921 – Finishing Intersection with FROZENSET : 2010-03-15
  12:41:57.922000
• 2010-03-15 12:41:57,921 – FROZENSET time : 0:00:00
• 2010-03-15 12:41:57,921 – Starting Intersection with FILTER : 2010-03-15
  12:41:57.922000
• 2010-03-15 12:42:00,421 – Finishing Intersection with FILTER : 2010-03-15
  12:42:00.422000
• 2010-03-15 12:42:00,421 – FILTER time : 0:00:02.500000
• 2010-03-15 12:42:00,421 – Verification. Difference entre meth1 et meth2 : 0 | et
  difference entre meth2 et meth3 : 0

Conclusions que l’on peut tirer de ce test :

Pour la différence : lambda toujours plus long, puis SET, puis frozenset.
Pour l’intersection :

• lambda est toujours plus long.
• Ensuite, le plus long entre set et frozenset dépend de la grandeur des deux objets à comparer.

  Si on a deux objets distincts, disons un grosObjet et un petitObjet :

  • grosObjet.intersection(petitObjet) => time(frozenset) > time(set)
  • petitObjet.intersection(grosObjet) => time(frozenset) < time(set)

Le code du test, comme promis :

def make_intersec(arg1,arg2):
# Make intersection between arg1 and arg2

    #Premiere methode : en utilisant SET
    startSET = datetime.now()
    logger.info("Starting Intersection with SET : "+str(startSET))
    setArg1 = set(arg1)
    setArg2 = set(arg2)
    intersecArg1Arg2meth1 = setArg2.intersection(setArg1)
    endSET = datetime.now()
    logger.info("Finishing Intersection with SET : "+str(endSET))
    logger.info("SET time : "+str(endSET-startSET))
    #Deuxieme methode, en utilisant FROZENSET
    startFROZENSET = datetime.now()
    logger.info("Starting Intersection with FROZENSET : "+str(startFROZENSET))
    frozensetArg1 = frozenset(arg1)
    frozensetArg2 = frozenset(arg2)
    intersecArg1Arg2meth2 = frozensetArg2.intersection(frozensetArg1)
    endFROZENSET = datetime.now()
    logger.info("Finishing Intersection with FROZENSET : "+str(endFROZENSET))
    logger.info("FROZENSET time : "+str(endFROZENSET-startFROZENSET))

    #Troisieme methode, en utilisant LAMBDA
    startFILTER = datetime.now()
    logger.info("Starting Intersection with FILTER : "+str(startFILTER))
    intersecArg1Arg2meth3 = filter(lambda x:x in arg1,arg2)
    endFILTER = datetime.now()
    logger.info("Finishing Intersection with FILTER : "+str(endFILTER))
    logger.info("FILTER time : "+str(endFILTER-startFILTER))

    result_methode_1 = frozenset(intersecArg1Arg2meth1)
    result_methode_2 = frozenset(intersecArg1Arg2meth2)
    result_methode_3 = frozenset(intersecArg1Arg2meth3)
    diffmeth1meth2 = result_methode_1.difference(result_methode_2)
    diffmeth2meth3 = result_methode_2.difference(result_methode_3)
    logger.info("Verification. Difference entre meth1 et meth2 : "+str(len(diffmeth1meth2))+" | et difference entre meth2 et meth3 : "+str(len(diffmeth2meth3)))

    result = list(intersecArg1Arg2meth2)
    result.sort()
    return result

def make_diff(arg1,arg2):
# Make difference between arg1 and arg2

    #Premiere methode : en utilisant SET
    startSET = datetime.now()
    logger.info("Starting Difference with SET : "+str(startSET))
    setArg1 = set(arg1)
    setArg2 = set(arg2)
    diffArg1Arg2meth1 = setArg2.difference(setArg1)
    endSET = datetime.now()
    logger.info("Finishing Difference with SET : "+str(endSET))
    logger.info("SET time : "+str(endSET-startSET))
    #Deuxieme methode, en utilisant FROZENSET
    startFROZENSET = datetime.now()
    logger.info("Starting Difference with FROZENSET : "+str(startFROZENSET))
    frozensetArg1 = frozenset(arg1)
    frozensetArg2 = frozenset(arg2)
    diffArg1Arg2meth2 = frozensetArg2.difference(frozensetArg1)
    endFROZENSET = datetime.now()
    logger.info("Finishing Difference with FROZENSET : "+str(endFROZENSET))
    logger.info("FROZENSET time : "+str(endFROZENSET-startFROZENSET))

    #Troisieme methode, en utilisant LAMBDA
    startFILTER = datetime.now()
    logger.info("Starting Difference with FILTER : "+str(startFILTER))
    diffArg1Arg2meth3 = filter(lambda x:x not in arg1,arg2)
    endFILTER = datetime.now()
    logger.info("Finishing Difference with FILTER : "+str(endFILTER))
    logger.info("FILTER time : "+str(endFILTER-startFILTER))

    result_methode_1 = frozenset(diffArg1Arg2meth1)
    result_methode_2 = frozenset(diffArg1Arg2meth2)
    result_methode_3 = frozenset(diffArg1Arg2meth3)
    diffmeth1meth2 = result_methode_1.difference(result_methode_2)
    diffmeth2meth3 = result_methode_2.difference(result_methode_3)
    logger.info("Verification. Difference entre meth1 et meth2 : "+str(len(diffmeth1meth2))+" | et difference entre meth2 et meth3 : "+str(len(diffmeth2meth3)))

    result = list(diffArg1Arg2meth2)
    result.sort()
    return result

AbriCoCotier.fr, 2010. | Permalien | Ajoutez un commentaire ! | Plugin Better Feed, par Ozh
Rangé dans : Programmation, Python (et Django)