un petit mémo tout con, mais qui peut-être utile. Il peut arriver d’avoir besoin d’afficher la version de django utilisé pour un projet précis. Comment faire ?
La fonction get_version() du __init__ de django est la pour ça.
Un petit from django import get_version est le tour est donc joué.
Comme d’habitude le mois d’aout fut une vraie folie. Et qui dit mois de folie dit, billet qui prennent du retard. Heureusement que j’ai pu tricher en publiant la première interview. (ben oui c’est beaucoup plus rapide de poser des questions que d’y répondre, enfin beaucoup plus rapide d’écrire les questions dans un mails quoi).
Du coup, je suis presque en retard pour la django app du mois. Et pour ne pas être en retard, j’ai choisi pour ce mois ci, une django app simple, mais très utile, django simple captcha (pour la petite histoire j’ai découverte cette app en testant django-tellafriend, une application dont il faudra que je vous parle également).
Alors on le trouve, tout simplement, sur la page google code qui lui est consacré. Pour l’installation, c’est comme toujours du classique (ha ce que j’aimerais un jour, avoir une surprise à ce niveau là, pouvoir gouter à un peu de nouveauté… mais non, c’est toujours pareil.
Vous avez donc le choix entre :
Dans tout les cas, il vous suffira une fois votre petite application installée, de la rajouter dans les INSTALLED_APP, de lancer un petit syncdb et magie… ça fonctionnera.
Enfin, si vous avez pensé à installer PIL, bien entendu.
La doc elle, est minimaliste mais plutôt claire et bien faite.
He ben mon cher ami, c’est indiqué dans le titre. C’est une application de captcha. Elle permet dans sa version de base de proposer trois méthodes de tests de l’utilisateur :
le très classique lettre dans le désordre
l’opération mathématique (toi aussi répond à 4+2)
le choix d’un mot, au hasard, dans un dictionnaire.
Et là, ou c’est vraiment le top avec cette petite app, c’est que si vous avez installé Flite, vous pourrez même avoir votre captcha en Text-so-speech, et vive l’accessibilité !!
En fait rien de plus simple, l’app fourni tout simplement un noueau type de Field a utiliser dans un formulaire.
Et oui, rien de plus simple.
On crée son formulaire, on rajouter un champ Captcha et quand le formulaire a été posté, on fait un joli is_valid() pour savoir si c’est bon.
Et au niveau de la configuration, les possibilités sont très complètes. On peut configurer le taux de bruit appliqué à l’image, les inclinaisons maximums appliqués aux lettres et aux chiffres, la font à utiliser ainsi que sa taille, les différentes couleurs, etc etc,
Ce qui est de bien avec cette app, c’est qu’en plus de penser à tout ce qui accessibilité, elle est bien pensé. Elle vous permet en effet de rajouter vos propres générateurs de tests. Il suffit de coder une petite fonction qui renverra un tuple contenant la question et sa réponse dans un tuple. Et le tour est joué.
Et ça c’est plutôt très sympa.
Dernière précision, la page google code contient un bouton flattr, si vous avez un compte flattr (cet excellent nouveau système de rétribution dont il faudra que je parle un jour, mais google est votre ami), n’hésitez pas à cliquer sur le bouton.
Le module itertools est un module bien pratique auquel on ne pense pas assez souvent. En tout cas auquel, moi, je ne pense pas assez souvent. Et pourtant, il peut grandement simplifier pas mal de ligne de code, dans un bon nombre de situation. Il faut juste savoir que les fonctions qu’il propose existe.
Ce billet a donc 2 objectifs, vous faire découvrir les itertools (je ne vais pas lister toutes les fonctions juste celles dont je devrais me servir plus souvent et que j’oublie) et me permettre de ne pas oublier que je pourrais les utiliser.
Point important : Un certain nombre des itertools permettent de gérer les iterateur infinis, ce que ne permettent pas les fonctions ‘normales’ comme map par exemple (qui renvoie une sortie complétement calculée, ce qui est par définition impossible avec un iterateur infini).
Précision : les exemples de code sont ceux fournis par la doc officielle des itertools
permet d’avoir un iterateur qui retourne tout les éléments du premier iterable passé en paramètre, puis du second, puis du troisième, etc etc… Bien pratique pour aérer son code.
Depuis python 2.6, il existe une classmethod de chain, from_iterable(iterable) qui ne prend qu’un argument, un iterable contenant tout les iterables.
compress n’est disponible qu’en python 2.7. Cette fonction retourne un iterateur contenant que uniquement les valeurs de data auxquelles correspondent un élément évalué à True dans le selectors. Compress s’arrête dès que data ou selectors est vide.
Cette fonction bien que présente depuis longtemps a droit à quelques modifications dans python 2.7. Count gagne en effet l’argument step et la possibilité d’itérer sur des arguments non integer.
Construit un iterateur qui ne renvoie aucun élément de l’iterable tant que le prédicat est vrai, ensuite, tout les éléments de l’iterable sont renvoyés
Construit un iterateur qui, tant que le prédicat est vrai, renvoie les éléments de l’iterable.
Construit un iterateur qui ne renvoie que les éléments pour lesquels le prédicat est respectivement True ou False. Si predicate est à None, l’iterateur renvoie les éléments respectivement True ou False.
Renvoie un iterateur qui applique function en utilisant les iterables comme argument. Si function est None, les arguments sont retournés sous la forme d’un tuple. Imap s’arrête lorsqu’elle atteint la fin du plus petit des iterables. Imap est utile lorsque l’on utilise des iterateur infinie qui provoque une erreur avec map.
Comme l’on trouve imap, il existe aussi izip, izip_longest et islice,
Parmi les autres fonctions il y a des fonctions de combinaisons, de calcul, de cycle, de groupby, mais celles là, vous les trouverez sur la doc officielle.
Et oui, malgré la chaleur, malgré les vacances, la plage et l’appel de starcraft 2, malgré tout cela, je reste fidèle au poste et je publie une django app du mois. Bon ok, c’est le dernier jour du mois, mais je suis encore dans les clous.
Mais par contre, vu que c’est l’été, les vacances, je vais pour une fois parler d’une app qui est pour faire tout sauf de la prod. C’est une app toute jeune et qui en plus s’aventure dans un domaine encore très peu supportés dans les navigateurs (pour l’instant uniquement dans Chrome 4, Firefox 4 et Safari 5) , celui des websockets. C’est quoi une websocket vous allez me dire ? C’est un mécanisme qui apparaît dans HTML 5 et qui permet d’avoir un mécanisme de connexion persistante et bi directionnelle entre le serveur web et le browser de l’utilisateur. Trop cool vous allez me dire. Je ne puis qu’être d’accord avec vous. (pour plus d’infos sur les websockets vous pouvez aller lire la page wikipedia ou la norme W3C qui est plutôt facile à lire).
Django-websocket est donc une toute récente app (version 0,3 à l’heure ou j’écris ce billet) qui permet de commencer à s’amuser avec ces adorables websockets.
Vous trouverez django-websocket sur sa page pypi ou sur sa page github. L’installation se fera donc soit :
Comme le code évolue pas mal et que de toute façon c’est pour l’instant plus une app pour tester et pas pour mettre en prod, moi, je vous conseillerais le git clone qui vous permettra d’avoir plus souvent une app à jour.
La documentation est plutôt bien fournie, claire et suffit pour démarrer. Le repository github permet d’avoir en plus les tests et une petite application example de echo.
En fait c’est vraiment super facile, il suffit d’utiliser deux décorateurs de vues soit :
Ensuite il n’y a qu’un seul objet à utiliser request.websocket sur lequelle on pourra :
Petite précision, le serveur de développement de django n’est pas multithread, il n’est donc pas possible d’ouvrir deux requêtes concurrentes avec. L’app fourni donc une commande spéciale pour le runserver ( –multithreaded ) qui permet de contourner le problème.
Histoire de m’amuser un peu avec l’app, j’ai commis un petit exemple avec, en me basant sur le echo exemple. Mon exemple est tout con, vous entrez une chaine de caractère et je lance (grâce à restkit) une recherche google toute les 30 secondes sur la chaine de caractère. Les dix premiers résultats de la recherche sont ensuite affichés grâce à la websocket.
Vous pourrez trouver le code en question sur le tout nouveau repository bitbucket que j’ai du coup, crée pour l’occasion.
La pluie ayant décidé d’être l’invité surprise du week-end, j’ai donc une bonne excuse pour ne pas aller prendre des coups de soleil à la plage mais rester bien tranquillement sur mon clavier. Autant donc en profiter pour vous parler de l’application django du mois, j’ai nommé django-improved-inlines. Oui, je sais, elle a un nom à rallonge. Django-improved-inlines est en fait une version légèrement dopé de django-inlines (d’où le improved) qui fait elle même parti du package django-basic-apps. Oui je sais, ça commence à faire un arbre généalogique digne d’une série américaine (ou du trône de fer).
Vous le trouverez sur sa page github. C’est d’ailleurs là que vous pourrez apprendre que cette sympathique petite app est une version modifiée de l’app inlines de django-basic-apps.
Pour l’installation deux méthodes :
directement en clonant le repository git de github
avec un petit easy_install bien de chez nous.
Attention, l’application pour fonctionner à besoin de BeautifulSoup mais l’installation par easy_install ne vous l’installera pas automatiquement. Un petit easy_install beautifulsoup sera donc de rigueur. Et oui.
Quand à la doc, elle tient dans un mouchoir de poche, à savoir le fichier readme mais au vu de la simplicité de l’app, ce n’est pas vraiment dérangeant.
En fait c’est tout simple. Cela vous permet, lorsque vous rédigez des contenus, d’insérer à l’intérieur d’autre contenu gérer par votre django. Et en les mettant en forme avec des templates spécifiques.
Imaginons par exemple que vous voulez insérez des images d’une manière simple dans un billet de blog, ou des blocks de texte ou ce que vous voulez en fait. Et cela, sans modifier le template de votre contenu principal. Et oui. Mais non, ce n’est pas de la magie.
En fait, cela marche en deux temps. Tout d’abord dans le template d’affichage de votre contenu principal, il faut déclarer et utiliser le template de django-improved-inlines, comme ceci :
Ensuite, tout va se jouer dans votre contenu, ici le body de votre post. Vous allez parsemer celui si de bouts d’xml qui seront process par BeautifulSoup et Improved-Inlines et qui seront transformés en html (grâce à un template).
L’exemple le plus simple est :
qui affichera l’objet de pk 1 qui est modélisé par la classe photo contenu dans l’app media.
Mais vous pourrez également utiliser les attributs xml suivant :
ids pour afficher plusieurs id, séparées par des virgules.
filter pour passer un filtre django
template pour choisir le template django qui sera utilisé (par défault l’app utilise inlines/app_model.html)
class qui permet de passer une class au template
ce qui donnerait :
ou encore :
Je n’ai pas encore eu l’occasion de m’amuser, ‘pour de vrai’ avec cette appli toute simple, ce n’est pas l’envie qui m’en manque parce que je pense lui trouver une foule d’application qui me faciliteront grandement la vie.
J’ai une seule petite appréhension que le process par BeautifulSoup ne ralentisse pas quelque peu le rendering des pages. Ca serait d’ailleurs un ralentissement à évaluer. En tout cas, amusez vous bien avec cette appli aussi simple, qu’utile.
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 …)
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 :
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.
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.
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.
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.
Poussé par les nombreux bilans que je vois fleurir sur le hastag #djangocong, je ne peux que participer et faire mon bilan perso de ce week-end de folie, (et comme je suis à la bourre, je le fais en dégustant mon jambon-beurre salé du midi).
Je ferrais un bilan plus ‘du coté de l’organisateur’ parce que des bilans ‘coté public’ il y en a déjà eu plein et des super complets, bien plus que ce que je pourrais faire (comme celui de laurent mais aussi de tous les autres présents, une simple recherche sur le hastag donnera tout les liens).
Pour commencer, les remerciements :
Pour le reste.
J’ai adoré ces deux jours de conférences. Et j’ai vraiment adoré les organiser. Que ce soit avant ou pendant. Plein de moment de stress (‘mais où va-t-on trouver un resto pour ce soir?’) ou de petits moment fun (comme appeler un resto pour lui dire ‘bon je vous réserve l’intégralité de vos couverts’ ).
Effectivement vouloir être intervenant en étant organisateur, ce fut une gageure qui fut difficile à tenir. Faire des slides entre minuit et deux heures du mat, pendant la nuit de samedi à dimanche (vous pouvez les trouver là ou sur slideshare), c’était rigolo mais fatiguant. Mais d’un autre coté, je suis content d’avoir pu parler un peu, d’un sujet qui me tenait à cœur, même si j’aurais voulu faire mieux, pour le coup.
Donc oui, voir que tout ce passait plutôt bien, que tout le monde était content, heureux d’être venu, fut une vraie joie et autant le dire tout de suite, une vraie motivation pour se dire qu’il faut faire un truc l’année prochaine (oui, je sais david, il faut débrieffer et qu’on en discute, tout ça,…. 🙂 )
Bien entendu il y a des choses à améliorer. Pour les repas, on a dérapé à chaque fois au niveau du planning prévu. Faut il passer sur une pause de 2h pour le repas, prévoir un traiteur ou trouver une troisième solution, il faudra étudier le truc.
Pour les conférences, elles furent effectivement super denses, s’enchainant à toute allure sans trop de pause. Est ce qu’il faut réduire le temps des confs, en faire moins, prévoir plus que deux jours de congs.. là aussi il y a plein de pistes à explorer (l’idée de david de partir sur un format un peu plus barcamp me semble une idée très intéressante) .
Laisser plus de place à des sprint code pourrait être intéressant aussi, à voir comment on mixe les eux. Plein de possibilité donc, pour la prochaine édition, si elle a lieu (ben quoi laissons un peu le suspense planer:) )
Au niveau logistique, plein de petit truc à améliorer pour la prochaine, David en a listé par mal, je rajouterais de prévoir plus de cafetière (au moins deux) pour pouvoir étancher plus facilement la soif des intervenants et ne pas faire confiance aux bus marseillais le dimanche matin :). Je suis sur qu’en se posant et en réfléchissant on trouvera d’autre petit trucs pour améliorer la logistique.
Créer l’asso, on s’y est un peu engagé au tout début des deux jours, et ça sera un pré-requis obligatoire, pour la deuxième édition, je pense.
Donc voilà, pour moi, c’est deux jours furent vraiment un plaisir de chaque instant.
Le dimanche soir, lorsque je me suis retrouvé seul dans le bâtiment, à vérifier une dernière fois que tout était niquel, en ordre, bien rangé, juste avant de charger le carton de cadavre de bière pour aller le jeter au recyclage, il faut bien avouer que j’ai eu un petit pincement au coeur en me disant ‘c’est déjà fini’.
Et puis je me suis dit ‘vivement l’année prochaine pour la deuxième édition’.
Alors voilà.
Bon, bien entendu mon titre est volontairement accrocheur. Et complètement mensonger. Mais il faut bien appâter le chaland un peu. Sinon, je ne serais jamais un blogueur influent.. Alors vive les titres accrocheur 🙂
Mais avant de commencer, il faut peut-être que j’explique ce que c’est que Titanium. Titanium c’est un framework assez génial (et libre) qui permet de faire du dev iphone/android en html/javascript. Histoire que ceux qui n’aiment ni l’objective-C, ni le Java puisse tout de même coder sur ces plateformes là. Histoire aussi de coder qu’une fois son appli et de la voir tourner sur les deux.
Là, vous devez être en train de vous demander : ‘Il va nous parler de dev iphone/android en js ? ‘
Et ben en fait, pas du tout.
Parce que là où Titanium est encore plus génial, c’est que l’on peut coder pour le Desktop aussi, en multiplateforme à savoir Linux, OSX et Windows. Sympa, vous aller me dire, mais bon faire toute une appli desktop en js, voilà quoi …
Oui, mais non, parce que pour le desktop, on peut coder en python (attention en python 2.5 uniquement), en ruby ou.. misère, en php. Et là, ça devient carrément miam.
Ca faisait donc plusieurs mois que j’avais envie de tester le bouzin, mais bon, j’avais déjà pas le temps de bosser sur histoiresderolistes.com alors tester un truc en plus… Et puis les tests c’est bien joli mais pour faire des Hello World! Merci.
Mais comme les vacances, ce n’est pas fait que pour travailler sur le boulot en retard, j’ai pu m’y mettre, un peu. (et puis faut avouer que le billet de @popofr13 sur le dev titanium iphone m’a boosté à écrire le mien). Restait alors le problème du Hello World. Après 30 secondes de réflexion je me suis dit que bidouiller des trucs avec twitter, ça serait rigolo. Et en plus comme c’est bien buzz word twitter, ça plaira, c’est sur.
Et c’est ainsi qu’un froid jour d’avril, une nouvelle catégorie d’article naquit sur le j-mad blog. Une catégorie dédiée aux bidouillages avec Titanium et ayant pour fil rouge le dev d’un client twitter basique (type Pino quoi). Et comme pour chaque projet, il faut un nom, j’en ai trouvé un TwittPouick. Oui je sais. Non, pas de commentaires sur le nom.
Alors c’est tout simple, pour télécharger Titanium, on va sur le site et on clique sur téléchargement.
Ensuite il n’y a qu’à décompresser l’archive et lancer l’installateur. Petite précision, il y a assez régulièrement de nouvelle version, qui sont indiqués directement dans l’interface de Titanium. Il suffit alors de relancer le cycle dl/décompression/installation.
Une fois Titanium installé et lancé, il suffit de cliquer sur New Project pour voir la fenêtre ci dessous apparaître. Rien de bien difficile à comprendre, il suffit de remplir les champs et de cliquer sur create project (N’oubliez pas de cocher en vert la petite case python tout de même).
Vous arrivez ensuite sur la fenêtre principale composé d’à gauche la liste de vos projets (sur mon screen on voit d’ailleurs mon projet twittpouick) et à droite ben la zone de droite avec un menu horizontal en haut Dashboard / Edit / Test & Package.
Ben ensuite, on prend son navigateur de fichier favori et on va voir ce qu’il nous à générer le tonton Titanium.
Et l’on voit ça :
Bon le fichier jquery n’est pas là de base, c’est moi qui l’est rajouté. Vous comprendrez pourquoi par la suite.
Donc il ne devrait y avoir quasiment que le fichier index.html. Qui correspond à notre fenêtre principale. Avant de partir pour de vrai dans des vrais choses rigolotes (comprendre le client twitter), on va tout de même faire un hello word. Et oui.
Ouvrez le fichier index.html et remplacez son contenu par celui-ci
Allez dans Test & Package, cliquez sur Launch App, une fenêtre blanche se lance avec un bouton, cliquez sur le bouton et mirage, une fenêtre Alert javascript s’affiche avec un Hello World dedans.
Ce qui est logique, si on regarde le code au dessus. On crée une section de code python, on définit une fonction que l’on appelle sur le onclick du bouton, dans un code js donc, et on passe le retour de la fonction python (je le rappelle) en paramètre à la fonction alert js.
En fait cet exemple, bien que très simple, montre la plupart des trucs génials de Titanium.
On peut déclarer des sections de code python, directement dans les fichiers html (mais on peut le faire proprement en dehors aussi, ça sera l’objet d’un prochain billet) et on peut accéder au python du js.
Et c’est aussi valable dans l’autre sens. On peut accéder du python, à du code JS. Que ce soit accéder à des fonctions ou à des variables, que l’on peut modifier, bien entendu (à ce propos, cette page de la doc officielle explique la conversion entre les types python / javascript.
Pour clore ce premier billet, déjà bien long, et justifier un peu, le titre du billet, on va faire une premier truc, c’est récupérer, après clic sur un bouton, sa timeline, dans un mode code grouirk, parce que c’est juste pour finir en beauté ce billet.
Je ne connais pas les librairies twitter en python. Et je n’ai pas vraiment le temps de me plonger dedans pour voir laquelle est la mieux. Par contre je connais bien restkit, une librairie bien bien sympa de @benoitc et qui marche plutôt bien.
On va donc l’utiliser pour récupérer sa timeline.
On à une interface HTML. On veut modifier le dom. Moi j’aime bien jquery. Donc on va utiliser Jquery. Directement dans du code python. Et oui. Comme si on était en Js. Sauf que l’on ne pourra pas utiliser le raccourci $ , vu qu’on est en python. On va donc simplement utiliser le vrai objet JQuery.
On peut bien entendu, encore heureux, utiliser directement les API titanium qui sont en Js. Pour l’exemple, j’utilise Titanium.API.info qui permet d’afficher une chaîne de caractère dans la console.
Bon et maintenant le code, complet, du fichier index.html
Vous n’avez plus qu’à installer restkit (avec easy_install), pour python 2.5 N’OUBLIEZ PAS !!!, mettre jquery à coté de votre fichier index.html, mettre votre login / mot de passe twitter et puis lancer l’appli twitter.
Cliquer sur le bouton, quelque seconde après .. miracle les tweets apparaissent. Recliquez sur le bouton, les nouveaux twitts s’ajoutent en bas de liste….
Et voilà, même pas 10 minutes et déjà vous avez un début de client. Comme quoi, je ne vous avais pas tant mené en bateau que ça, dans mon titre, finalement.
Ce premier billet, n’est qu’un premier billet. Il ne va pas très loin dans la présentation de Titanium, parce que je n’ai pas vraiment eu le temps de moi même faire plus. Vivement les prochains billets donc. Enfin, j’espère que c’est ce que vous vous dites en ce moment :).
Pour la suite, je mettrais en place un repository mercurial sur bitbucket où je déposerais les différentes étapes de la création de TwittPouick.
En attendant mon prochain billet, amusez vous bien avec Titanium.
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.
On le trouve à deux endroits :
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.
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 :
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
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
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.
‘C’est l’histoire d’un mec …’ qui était rôliste.
Bon ok, c’était facile, mais je trouve que c’est une bonne façon de démarrer ce billet. Billet tout entier consacré à de l’autopromo ou plutôt à l’annonce du lancement d’un de mes side-project comme on dit.
Histoiresderolistes.com. Né d’une idée toute simple à savoir que les rôlistes, dont je suis, adorent se raconter leur vieilles histoires de joueurs, leurs souvenirs de catastrophe évitées ou de justesse, ou pas du tout, leur grand moment de rigolade. Et parfois on a envie de partager ces histoires, pas seulement avec son groupe de joueur actuel, mais avec ses anciens compagnons de parties, ou même avec d’autres rôlistes tout court.
Comme je n’ai pas trouvé un tel endroit, je me suis dit que j’allais la bâtir moi même, la petite taverne virtuelle où nous pourrions tous être barde, le temps d’une histoire.
Alors ce ne fut pas facile de venir à bout de ce projet, dont la taille est pourtant plus que petite. Pour donner une idée de la chronologie :
Mais maintenant, il est en ligne, et vous pouvez aller y lire/raconter des histoires de rôlistes. Et si il est en ligne, c’est aussi grâce à ma chére et tendre qui a été la première des béta testeuses, bien qu’elle ne soit pas du tout rôliste… Le fait qu’il n’y est pas de fautes d’ortographes sur le site (ou presque pas) est par exemple complètement grâce à elle, mais ce n’est pas son seul apport, loin de là.
Et ce n’est pas qu’un ‘simple’ site où les gens soumettent des histoires. Quitte à lancer un truc, autant s’en servir comme bac à sable, pour tester des choses dont je parle dans mes billets.
Comme par exemple, l’introduction de mécanismes tirés des jeux vidéos, comme les titres et succès (qui sont ici appelés badges).
Vous pourrez donc gagner des titres (top posteur par exemple) ou des badges comme le badge du djinn narcissique ou du gobelin fanatique (liste des badges). Exactement comme dans les jeux, vous ne connaitrez pas la manière de débloquer certains badges. Parfois même, vous ne saurez même pas que les badges existent avant de les débloquer.
Ce n’est bien entendu qu’un début, j’ai plein d’autres idées (dont certaines déjà listées dans les billet du ce blog), que je mettrais en place petit à petit. En essayant, ensuite, d’analyser le retour des utilisateurs à mes ‘expériences’.
Mais déjà, la question est de savoir si h2rolistes (et il y a même un twitter et un identi.ca pour suivre les nouveautés) va trouver son public ou non…
Et bien entendu, h2rolistes c’est du 100% django.
Ce billet n’est qu’un petit mémo rapide, pour éviter que d’autre perdent comme moi du temps à chercher un problème qui n’en est pas un. Si jamais je me trompe dans mon interprétation du problème et dans la solution que j’en donne, je suis preneur d’une explication / correctif dans les commentaires.
Django embarque, dans les contrib, un petit framework pour géré la syndication. Plutôt bien foutu d’ailleurs.
Il fonctionne suivant un principe assez simple, pour chaque flux on définit une classe, ensuite on range les classes dans un dict où la clé sera le nom du flux dans l’url et la valeur, la classe, que l’on passe en paramètre à la vue qui gère l’ensemble des flux. (tout est parfaitement expliqué dans la doc, ici).
Par exemple :
ici on aura donc deux urls :
On peut définir deux templates celui pour justes les titres et celui pour l’item RSS complet. Les deux templates doivent avoir pour nom :
Soit dans notre exemple :
Et tout fonctionne parfaitement dans le meilleur des mondes.
Maintenant prenant un exemple un peu plus compliqué. Imaginons deux apps django, une pour gérer un blog, une pour gérer des reviews de films.
Les deux apps vont donc mettre en place des flux RSS, logique.
Et les deux vont vouloir mettre en place le flux latest. Donc dans chaque répertoire templates des apps, il y aura un sous-répertoire feeds avec les fichiers latest_title.html et latest_description.html
Et là, patatra. Le deuxième flux (dans l’ordre des INSTALLED_APPS) va utiliser les fichiers templates du premier. Parce qu’apparement la recherche des templates pour les feeds et transversale.
Donc faut nommer de manière différentes ses flux. latestblogs et latestreviews par exemple.
Et là, miracle, ça fonctionne.
Voilà, c’est tout.
Les queryset sont une des composantes importantes de Django. Comment en effet interagir avec la BD sans eux ?
Mais est ce que cet outil si important et si souvent utilisé est si bien connu que ça ?
Parce que tout le monde connait count(), filter(), all() et exclude(). Mais qu’n est-il des autres méthodes ? Perso, je suis le premier à aller dans la doc, pour revérifier si ce que je voudrais n’existe pas déjà…
C’est le pourquoi de ce billet, lister quelques méthodes ‘à connaître’ des querysets (et puis comme ça la prochaine fois que j’aurais besoin de vérifier un truc, je pourrais le faire en lisant du français et pas de l’anglais). (Ce n’est au final qu’une redite de la page de doc qui va bien, mais ça peut servir).
une petite méthode bien pratique, qui permet de rajouter des colonnes calculées (en utilisant les classes d’agrégat Sum,Count, etc défini par django) pour chaque objets récupérés dans le queryset.
Et ça, c’est plutôt fort. Surtout que l’on peut, bien entendu, ‘traverser’ les foreign key
L’un des exemples de la doc, montre cela en calculant pour un magasin le prix minimum et maximum des livres en vente :
Deux méthodes plus que miam.
Values retourne un ValuesQuerySet qui est en fait un queryset composé d’une liste de dictionnaires au lieu d’une liste d’instance d’objet modèle. Chaque dictionnaire représente un objet, les paire clés / valeur représentant le nom de l’attribut (la key) et la valeur de l’attribut (sa valeur).
On peut passer à values un paramètre optionnel *fields, qui permet de spécifier la liste des noms d’attribut (des strings donc) que l’on veut récupérer.
Exemple :
Deux choses importantes à se rappeler, values ne récupère rien pour les manytomany et dans le cas des FK, la clé du dico est le nom ‘vrai’ de l’attribut dans la table (souvent avec _id donc) et la valeur, la valeur de la PK de la FK. Et comme le voit dans l’exemple, si on veut passer le nom explicite de l’attribut de la fk, on peut au choix mettre ou pas le _id, le résultat est le même.
Exemple :
values_list c’est à peu près la même chose que values, sauf que c’est une liste de tuple et pas une liste de dico. On peut en plus lui passer un paramêtre flat que l’on peut mettre à true , pour ‘aplatir’ les tuples quand l’on demande qu’un seul champ (juste coolos quand on veut une liste de pk)
L’intérêt c’est qu’un ValuesQuerySet, c’est comme un queryset. Et que donc on peut utiliser toutes les méthodes des queryset dessus. Y compris refiltrer, order_by, etc etc ..
Et que dans le même temps, on peut alléger la charge, surtout si on a des gros models dont l’on ne veut utiliser que quelques champs.
Permet d’indiquer au queryset de ne pas récupérer automatiquement le contenu des champs qui sont passés en paramêtre du defer. Ca peut être utile dans le cas de gros champ texte par exemple (imaginons une vue en liste de billet de blog où l’on ne veut que les titres des billets et pas leur contenu, utiliser un defer(‘body’) pourrait être une possibilité , utiliser un values en serait une autre)
les champs deferred seront récupérés quand on les appelera explicitement. Pour annuler les defer d’un queryset, il suffit d’appeler la fonction avec None en paramêtre.
C’est l’inverse du defer, on ne récupère que certains champs.
Cette petite fonction bien sympa prend une liste de pk et renvoie un dico des objets qui correspondent (les clés étant les pk)
Renvoie le dernier objet, inséré dans la base, en se basant sur les dates et en utilisant le champ passé en paramètre (qui doit donc être un champ date).
Si le model en question définit la Meta get_latest_by, on peut appeler latest sans argument.
Ok, cette fonction ‘ne sert à rien’ à part pour rendre plus lisible le code. Mais bon, ça ne mange pas de pain. Et l’utilisation de la Meta get_latest_by permet de ‘centraliser’ la façon de rechercher le dernier, ce qui rendra une modification plus facile.
Retourne un dico des valeurs d’aggrégat calculés non pas objet par objet comme avec annotate, mais sur tout le queryset.
A vous les sommes de champ, les moyennes ou autre. Vive les rapports :).
et comme pour annotate, on peut contrôler le nom, ici de la clé, que notre valeur calculée.
cette fonction n’existe pas encore dans django, elle sera présente dans la 1.2. Elle permet tout simplement de savoir si le queryset est vide ou pas. (oui je sais, devoir attendre la 1.2 pour avoir cette fonction.. mais bon 🙂 ).
