Ce mois-ci, j’aurais pu écrire plusieurs django-app du mois. Si j’avais eu le temps. Mais bon, le jour où j’aurais le temps, ça se saura. Du coup, alors que l’horloge tourne et qu’il ne me reste plus qu’un jour et demi pour écrire ma django app du mois et mon polargeek, j’ai décidé d’écrire ma django-app du mois pour parler de django-qsstats, une petite application comme je les aime.

C’est à dire, qui ne fait qu’une chose, une toute petite chose, mais qui la fait bien. Et qui du coup est facilement intégrable, sans remord.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

On la trouve sur sa page github. Il me semble bien que le seul moyen d’installation soit à travers github. Mais bon, cloner un repository git hub, ce n’est pas le plus compliqué.

La doc, elle, se limite au fichier Readme et à la lecture des tests. Mais bon, honnêtement, cela suffit.

Par contre attention, en plus de nécessiter django 1.1 à minimal, cette petite app a besoin de python-dateutil (une petite librairie qui ajoute pas mal d’extension plutôt puissante à datetime, si vous ne connaissez pas, je vous recommande vivement d’aller jeter un oeil (mais pas les deux, après vous ne pourrez plus lire la doc … ) )

2- Mais au fait, à quoi ça sert ?

A presque rien, mais c’est bien utile.:) Lorsqu’on veut faire un minimum de stats, de comparaison ou autre, on se retrouve assez vite à vouloir trouver combien il y a eu de nouveaux articles la semaine dernière, combien d’histoires ont été écrites par des rôlistes durant le mois dernier, ou d’utilisateur enregistré les 6 derniers mois…

Faire cela est très simple, un petit queryset puis des petits filters. C’est très simple, mais bon, c’est rapidement chiant, et puis c’est pas très DRY.

Donc on se retrouve assez vite à faire des petits fonctions pour avoir les dates du mois en cours, ou d’un mois précis..

Où alors on se dit que quelqu’un à surement du le faire à notre place, on cherche un peu et on tombe sur django-qsstats.

3- Comment ça marche ?

C’est vraiment tout simple. Il suffit de mettre l’app dans son python-path. Ensuite un peu l’utiliser. Rien à faire de plus. Même pas de syncb vu que c’est une app sans model. (il y a un fichier models mais il n’est là que pour les tests).
Ensuite, ben un exemple sera plus parlant (je reprend l’exemple du site officiel)  :

Vous le voyez, c’est assez facile. On construit son queryset et ensuite on le passe à qsstats en lui indiquant le champ date qui devra servir au filtrage.

Déjà là, ça serait pas mal. Mais il y a mieux. Il existe la fonction time_series qui permet de récupérer une liste de valeur. Par exemple :

qui donnera :
New users in the last 7 days: [3, 10, 7, 4, 12, 9, 11]

Si cela itère par jour, ce n’est pas magique, c’est parce jour (enfin day) est l’argument step par défaut. Mais on peu bien entendu changer la taille du pas.

Enfin, par défaut, toutes les fonctions utilise Count pour calculer les résultat. (et quand je dis Count, c’est effectivement la class Count des Aggregat de django) Mais on peut changer ce comportement en donnant une valeur au paramètre agregate_class du QuerySetStats.

4-Conclusion

Comme je le disais en introduction, j’aime beaucoup les petites apps qui font des petits trucs, mais qui le font bien. C’est bien souvent plus utile que les grosses apps qui font tout et le café et qui sont bien plus difficile à intégrer (ceci n’est pas une critique de pinax hein, ne me faite pas dire ce que je n’ai pas dit).

Donc j’aime forcément, beaucoup qsstats.

Une petite information un fork de qsstats a été créé, sur bitbucket (et que vous trouverez sur pypi). Il s’appelle django-qsstats-magic. Il rajoute la gestion des heures et des minutes, une optimisation qui fonctionne avec mysql et modifie des trucs en interne. Mais effectivement, je n’ai pas poussé plus loin mes investigations.

J’ai déjà fait, il y en fait 11 mois, un billet de la django app du mois sur une app de tag, django-tagging. Lorsque je l’ai testé, django-tagging était à la version 0.3. Aujourd’hui, elle est version 0.3.1. Et les derniers commit remonte à janvier 2010 ( ce sont ceux ayant aboutis à la version 0.3.1)

Je me suis donc dit, qu’il était peut-être tant de revenir sur le sujet et de présenter une autre app django, sur le même sujet, qui même si pour l’instant présente quelques lacunes comparée à django-tagging, me semble prometteuse.

Et cette app, c’est, roulement de tambour…., django-taggit d’Alex Gaynor (un trublion bien connu pour ceux qui font du django)

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Alors on le trouve tout simplement sur sa page Pypi ou sur sa page github d’ailleurs

Pour l’installation rien de plus simple :

• un easy_install ou un pip
• un git clone

Pour la doc, là il n’y a vraiment rien à redire, le projet offre une doc très bien fournie sur readthedocs.org.

2- Mais au fait, à quoi ça sert ?

Tout simplement à taguer des objets. Exactement comme django-tagging donc. Vous allez pouvoir taguer vos objets, filtrer les objets en fonction des tags qu’ils ont ou trouver des objets similaires de par leur tag.

Vous allez aussi pouvoir modifier légèrement la mécanique interne. Par exemple si utiliser des generics key ne vous plait pas, tout est prévu pour que vous puissiez simplement les remplacer par des foreign key. Vous pourrez aussi changer d’autre mécanismes comme le model utilisé pour sauver les Tags.

3- Comment ça marche ?

Tout d’abord il faudra que vous ajoutiez, pour chaque models que vous voulez rendre ‘tagable’ un manager de tag. (Pour ceux qui se souviennent django-tagging permet de taguer directement des instances de models, sans modifier la classe Model en question).

Ca peut paraître un peu lourd et ça rend l’app assz intrusive, mais bon, c’est comme ça. Et puis du coup ça permet, il faut bien l’avouer d’avoir une écriture plus fluide et plus ramassé de son code. Nul besoin de toujours passer par la classe Tag en filtrant sur l’objet dont l’on veut récupérer les tags. Un simple object.tags suffit pour avoir tout ses tags.

Facilité d’utilisation ou intrusivité, à vous de choisir, django-taggit, lui  à choisit. (Et bon, au pire, un bon petit contribute_to_model devrait permettre une extensibilité moins intrusive).

Pour ajouter les tags, les syntaxes possible sont à peu près les mêmes que celle de django-tagging, à savoir (l’image est une capture d’écran d’une partie de la doc) :

Un truc à ne pas oublier, django-taggit utilise des many to many. Donc, n’oubliez pas le save_m2m si vous utilisez des forms.

Ensuite, vous pourrez bien entendu supprimer des tags, les lister, filtrer des objets en fonction de leur tags ou avoir une liste des objets similaires. C’est une vrai liste qui est classée par ordre de similarités.

4- Une app peut en cacher deux autres.

Là, à cette instant de votre lecture vous vous dites peut-être ‘Mais mer..mince alors, il manque des trucs comparés à django-tagging, il n’y a même pas de templates tags d’affichage’.

Et vous auriez raison. Sauf que, sauf que… Il y a des applications qui étendent django-taggit à savoir :

• django-taggit-suggest qui permet d’ajouter des fonctionnalités de suggestion de tags
• django-taggit-templatetags qui offre différents templatetags d’affichage des tags, dont un par cloud.

5- Au final

Vu le statut de quasi moribond de django-tagging comparé à la vigueur actuelle de django-taggit, je pense vraiment que si vous avez besoin d’une application qui gére les tags, django-taggit est un meilleur choix. Et puis, je trouve ça rassurant qu’il y ait des applications externes pour étendre django-taggit.

Le mois de mai est toujours un mois compliqué. Normalement c’est à cause de tout ces jours fériés qui sont autant d’obstacle au travail et qui nous oblige à être tout le temps en retard en mai. Pourtant, cette année, malgré que deux des jours fériés de mai tombent un samedi et que le dernier (demain) soit un jour travaillé pour moi, la malédiction du mois de mai a encore frappé et je n’ai de temps pour rien… A croire que c’est le mois de mai lui-même qui a pour conséquence que l’on soit en retard. La malédiction sanglante du mois de mai … (tiens on pourrait faire un bon film de série B avec ça). Enfin, tout ça pour expliquer le fait que l’application du mois que j’ai choisi est une toute petite application, que je n’ai en fait pas eu l’occasion d’essayer ‘en vrai’. (et puis bon, je n’allais pas cracher sur la possibilité de faire un jeu de mot coolos en parlant d’un film que j’adore …)

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

On le trouve sur la page github qui va bien et c’est tout. Quand à la doc, elle est, elle aussi uniquement sur le github

La doc se découpe d’ailleurs entre :

• le Readme
• le Install
• les commentaires dans le code.

C’est peu vous aller me dire, mais vu que l’app fait, en tout et pour tout, moins de 200 lignes, c’est suffisant.

2- A quoi ca sert ?

A remplacer le model django.contrib.auth.models.User par un des siens, d’une façon propre. Pour aider encore plus, des models spéciaux de M2M, de OnetoOne et de FK sont fournis pour quand on voudra créer des références vers nos nouveaux users.

3- Comment ça marche ?

Il y a deux façons possibles de le faire marcher.

En l’installant puis en l’utilisant. Tout simplement.. On créé son model, on utilise la fonction get_user_model() qui est fournit avec django-samaritain (ou en utilisant directement notre model d’ailleurs). Et on utilise les spécialisations des FK,OtO et M2M.

En utilisant la méthode de Monkey Patching pour injecter à la volée le comportement de django-samaritan dans un projet existant. Cette deuxième méthode est déconseillée pour une utilisation à long terme,dixit l’auteur de l’app lui même.

3- Retour ?

Et oui, je sais, c’est un comble. Mais bon, c’est mes billets, alors je fais ce que je veux. Donc, si l’un de vous a des retours sur l’utilisation de cette app, je suis bien entendu preneur, ne vous gênez surtout pas.

Et non, vous ne rêvez pas, on est même pas le 15 avril et déjà, déjà, le billet de l’app django du mois est là. Mais bon, les rencontres django ayant lieu dans maintenant 14 jours et n’ayant pas encore commencer à préparer ma conf, même pas le premier mot (enfin si, bonjour), ce qui fait que je suis ‘dans la banade’, comme l’a fait si justement remarquer il y a peu @daks_

Donc, je préfère me ‘débarrasser’ tout de suite de l’app du mois, comme ça, ça sera au moins une chose de faite.

Ce mois-ci, je vais donc vous présenter django-request, une app pour faire des stats sur la fréquentation de votre django. Oui je sais il y a google analytics pour ça. Mais bon, on sait jamais, ça peut être utile quand même.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

On le trouve à deux endroits :

• sur le github qui va bien
• sur les pages dédiées sur le site de son auteur.

A noter que quasiment toute la doc se trouve être sur la partie dédiée à django-request sur le site de son auteur.

Pour l’installation, facile, un git clone, un téléchargement de source ou alors pip et easy_install.

Quand à la doc, elle est vraiment très fournie et complète, permettant d’installer, de configurer, d’utiliser, la totale quoi.

2- A quoi ca sert ?

Ben à faire des stats, je l’ai déjà dit. Qui ne seront visibles que dans la partie admin.

On peut avoir de jolis graphiques concernant :

• les visiteurs uniques
• les visites basées sur des referrer différents
• les requêtes reçues par le serveur
• les requêtes venant des moteur de recherches
• les requêtes provenant du javascript
• les requêtes en SSL
• les requêtes faites par un utilisateur
• le nombre d’erreur 404
• le nombre d’erreur, toutes erreurs comprises
• le nombre d’utilisateur enregistré sur le site qui ont fait des requêtes

Par défaut les calculs seront fait pour les visiteurs uniques, les visites en fonctions des referrers et le nombre global de requêtes.

On obtient ensuite un joli petit graphique qui nous donne tout plein d’infos. Et plein de petits tableaux pour en avoir encore plus.

Et on peut même avoir, des petits templates tags pour voir les users actifs sur le site

3- Comment ça marche ?

Il suffit d’ajouter ‘request’ dans ses installed_apps et d’ajouter le middleware qui va bien. (Attention suivant les middlewares déjà installés, la position du middleware de django-request, dans le tuple des middleware est importantt, mais c’est bien expliqué dans la doc).

Ensuite, tout ce passe dans l’interface d’admin

4- Tips de chez Jmad.

Quand j’ai installé le tout avec easy_install, j’ai oublié de rajouter les chemins pour avoir les templates admins de l’app. Résultat je n’avais rien dans l’admin. Faites y attention ou alors installez request directement dans votre projet django, comme une de vos apps.

Le model Request présente un champ language qui est modélisé en bd par un varchar de 25. Avec mes tests, cette longueur était bien trop petite pour mon firefox. Du coup boum une erreur BD a base de ‘machin qui a été truncated’. J’ai passé la taille du champ à 200 pour être tranquille.

Les différents fichiers js qui sont utilisés sont bien entendu fournis. Pourtant par défaut, les templates vont utilisés ceux hostés ailleurs (sur le site web de l’auteur par exemple). N’oubliez pas de changer cette option si cela vous dérange.

C’est expliqué dans la doc, mais je le redis ici. Une fois que tout est bien configuré, pour aller voir ces stats, vous allez dans l’admin, vous cliquez sur la ligne Request de l’app Request. Là vous avez la liste de toutes les requêtes. (pas très utile là comme ça, vous me direz). Levez les yeux, en haut à droie, à coté du bouton Add Request, vous avez un bouton Overview. Et voilà, cliquez, vous avez vos stats.

Vous aimez mon titre ? Parce que moi, j’en suis super fier en fait. Et oui, il m’en faut peu. Bon donc pour la django-app du mois de février, j’avais choisi django-transmeta qui permettait de traduire facilement son contenu. Mais un site n’est pas fait que de contenu, il est aussi fait de label, de menu, de tout plein de truc qu’il faut internationaliser à coup de .po et de .mo. Ce qui est, il faut bien le dire, un poil chiant. Limite je pourrais dire, qu’à vouloir traduire tout ces mots, on pourrait bien finir par y laisser notre peau.

C’est là que django-rosetta intervient.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Comme bien souvent, sur la page qui lui est destiné, qui est, un google code. Pour l’installation, rosetta fait dans le rustique : tar.gz ou svn checkout. Brut mais efficace.

Ensuite il suffira de rajouter django-rosetta dans les INSTALLED_APPS  et de rajouter ses urls dans l’urlpattern qui va bien. Et c’est tout, après roule ma poule (ou ma pierre, de rosette HA HA).

Pour la doc, la encore, il n’y a que la page home du google code. Mais l’app est suffisament bien faite, pour que la doc présente soit amplement suffisante.

2- Comment ça marche ?

Django-rosetta vous permet de rendre la rédaction des .po moins chiante que dans un simple gedit. Mais du coup, cela veut dire que l’application a besoin d’avoir les permissions d’écritures sur certains des fichiers de votre arborescence.

Du coup, elle n’est utilisable que de l’admin django. C’est un choix qui me semble, en fait, très logique. Et puis est ce que cela existe des gens qui n’utilisent pas du tout la partie admin de django ?

Ensuite, c’est tout simple, on a une liste des fichiers po, avec les pourcentages de traduction effectuées. On en choisit un et on se met au boulot. On peut même choisir si l’on veut afficher toute s les chaines ou que celle que l’on n’a pas encore traduite.

Allez op, deux petites images pour vous montrer le truc, parce que je suis gentil. (Et puis que je ne me suis pas trop fatigué, je reprend honteusement celles du google code officiel).

Voilà, avec cette deuxième app, j’en ai fini de parler, en tout cas pour un temps, d’internationalisation. A bientôt (dans un mois) pour de nouvelles découvertes dans le merveilleux pays des app django.

Et oui, vous ne rêvez pas, malgré le fait que le mois de février soit ridiculement court, je trouve tout de même le temps d’écrire mon billet de l’app django du mois. Comme quoi, tout arrive.

Bon il faut dire, que j’ai du coup sélectionné une app assez petite, que j’ai découvert grâce à #django-fr (merci les gars) et avec une doc très bien conçu que je vais donc pouvoir honteusement recopier en parti pour vous expliquer comment cela fonctionne.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Sur la page qui lui est dédiée sur google code. Et pour l’installer, point de tar.gz, de easy_install ou de pip. Le seul moyen de l’installer consistera à faire un bon vieux svn checkout des familles.

Au niveau de la doc, il n’y a que la page du project home du google code. Mais par contre, elle est super bien foutue.

Rendre heureux aussi, ceux qui ne parlent pas français (personne n’est parfait 🙂 ).

Django-transmeta tente de répondre à un besoin tout con, comment traduire efficacement son contenu, lorsqu’on a un site multi langue. Parmi tout les moyens imaginables pour faire cela (j’en reparlerais en fin de billet), transmeta a choisi de modifier directement les tables des modeles à contenu traduisible.

2- Comment ça marche ?

Je vais reprendre, texto, les exemples donnés par la page web de transmeta, parce qu’ils très clairs. Prenons l’exemple d’un model qui décrit un bouquin.

Tel que :

Là, rien n’est traduisible. Imaginons que l’on veuille traduire la description et le body. Rien de plus simple, le code du model devient alors :

On rajoute une metaclass et on défini dans la classe méta, les champs que l’on veut traduire.

Il faut ensuite, dans le settings.py, définir les langues que l’on veut gérer, par exemple :

Et qu’est ce que cela fait ?
Un petit manage.py sqlall va vous le dire :

apparaît ici la solution utilisé pour transmeta. Chaque champ qui est défini comme traduisible donne lieu à n champs en bd, pour n langues.

Là vous allez me dire : ‘Ok, bien cool, mais comment on fait quand on rajouter une langue ou que l’on veut faire en sorte qu’un champ existant qui n’était pas traduisible le soit ?’
Forcément, c’est prévu. Sinon, je n’aurais pas osé faire de billet. Donc il y des commandes manage.py spécial pour altérer les tables déjà existantes et permettre de rajouter soit des langues, soit des champs traduisibles.
Dernière chose, il y a tout ce qu’il faut de prévu pour pouvoir gérer ses champs dans l’admin.

3- Retour sur la méthode

Le principe de fonctionnement de transmeta implique de devoir utiliser des alter table à chaque fois que l’on veut rajouter une langue ou un champ. J’avoue que je n’ai jamais aimé les alter table sur du sql. Est ce un tort que j’ai ? Je ne sais pas.
Vous me direz que si l’on utilise pas d’alter table, on se retrouve presque les mains liées et qu’il ne reste que peu de solution, à part des grosses tables sous la forme ‘langue code’, ‘field name’, ‘trad’. Il est vrai. Mais bon, j’aime pas les alter table.

4- Retour sur le titre du billet :

Tout le monde aura compris, bien entendu, le jeux de mot. C’est une référence directe à transmeta, l’entreprise américaine qui faisait des processeurs ni ne chauffaient que très peu et qui donc n’avait pas besoin de ventilo. D’où le sans suer. C’est nul, je sais.

Je sais, je suis impardonnable, je n’ai pas fait de billet sur la django-application de décembre. Vous pourriez même rajouter que je le suis encore plus parce que décembre c’est le mois des vacances de Noël et que qui dit vacances dit temps pour écrire un billet.

Oui, mais non. Parce que faut pas croire, ça prend du temps tout ces repas de fêtes. Plein de temps. Sans compter le temps que l’on passe à arpenter les magasins (IRL ou sur le net d’ailleurs) pour trouver des cadeaux. Et sans parler du fait que comme décembre est un mois de vacances, pendant les jours de non-vacances, faut bosser encore plus pour essayer de faire autant que pendant un mois normal, mais en moins de jours.

Autant dire que non, je n’ai pas eu le temps pour la django-app du mois.

Et que vu mon emploi du temps en janvier, ça va être tendu pour le billet de celle de janvier. Mais, mais, dans ma grande mansuétude, j’ai décidé de faire un billet de django app du mois de décembre, en retard.

Et pour une fois, je ne parlerais pas de django-app, mais de middleware. Mais oui, les middleware django, vous savez, ce mécanisme génial qui permet de pluger de petit bout de code à différents niveaux de traitement des requêtes. Ce qui permet de modifier plus ou moins profondément le comportement de django au niveau de la gestion de ses entrées / sorties.

Ca permet de faire plein de trucs, et plus encore.

Aujourd’hui je parlerais de deux d’entre eux, un que j’utilise très souvent et un autre que je vais utiliser sous peu..

1- Loguer les requêtes SQL que fait django

J’ai trouvé ce tout petit middleware sur djangosnippets. Il se contente d’afficher la liste de toutes les requêtes SQL faites par django, en donnant le temps pris par leur execution.

C’est bien utile pour vérifier que ces vues ne font pas de la merde et pour tenter d’optimiser en factorisant des choses.

2- Django-maintenancemode

Celui-là, je l’ai découvert au détour d’une conversation sur #django-fr. Carrément plus pratique que la bête page html qui dit ‘en maintenance’, utile à connaître et à avoir dans sa django-boîte à outil.