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).

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

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 :

• easy_install
• un tar.gz de la dernière release
• un checkout de SVN

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.

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

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é !!

3- Comment ça marche ?

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,

4- Mais encore

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

itertools.chain (*iterables)

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.

itertools.compress(data, selectors)

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.

itertools.count(start=0, step=1)

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.

itertools.dropwhile(predicate, iterable)

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

itertools.takewhile(predicate, iterable)

Construit un iterateur qui, tant que le prédicat est vrai, renvoie les éléments de l’iterable.

itertools.ifilter(predicate, iterable) et itertools.ifilterfalse(predicate, 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.

itertools.imap(function, *iterables)

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.

les autres i-versions des fonctions classiques.

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 grouby, 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.

1- Où on le trouve, comment on l’installe, la doc.

Vous trouverez django-websocket sur sa page pypi ou sur sa page github. L’installation se fera donc soit :

• avec easy_install
• un git clone

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.

2- Comment ça marche ?

En fait c’est vraiment super facile, il suffit d’utiliser deux décorateurs de vues soit :

• require_websocket pour obliger la vue à fonctionner en websocket
• accept_websocket si l’on veut permettre à la vue de fonctionner sans les websockets.

Ensuite il n’y a qu’un seul objet à utiliser request.websocket sur lequelle on pourra :

• faire des attentes et récupérer un message quand il y en a un (wait)
• vérifier si il y a des messages ( has_messages )
• lire un message ( read )
• envoyer un message ( send )
• les utiliser comme un iterator (ce qui ferrait comme un wait dans une boucle avec la gestion en plus de la fermeture de la socket )

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.

3- Un petit Mad Exemple

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.

Hier soir, dans plusieurs villes de France, se déroulait le premier AFPYro National. Les amateurs du langage de programmation Python se retrouvaient régulièrement pour un apéro sympa, mais pour d'obscures raisons centralistes, cet apéro se déroulait exclusivement à Paris. En France. Il paraît.

Récemment, j'ai été chaleureusement convié à participer au premier AFPYro Palois.

Très bonne ambiance, gens apparemment curieux du langage, de ses bonnes pratiques ; on s'était promis de se revoir, tout ça.

Et au détour d'une conversation sur IRC, voilà-t-y pas que l'idée surgit d'organiser un AFPYro - pas seulement à Pau - dans toute la France. La date retenue : le 28 juillet au soir. Bon j'avoue que cette date était loin de m'arranger, aussi je ne pouvais pas faire le déplacement à Pau. Et je n'avais pas le coeur à organiser un truc tout seul de mon côté, aussi je m'abstins. C'est ainsi qu'au quatre coins de l'hexagones (on ne se lasse pas de cette incongruité géométrique), se tint le premier AFPYro National : à Pau, Paris, Toulouse, Nice et Metz. Et peut-être ailleurs...

Et moi qui pensais que Python n'était pas répandu à Bayonne... Je me trompais.

Déjà, dans la ville, depuis quelques temps, je voyais bien que quelque chose était en train de se tramer... des tonnes de palettes de boissons diverses débarquaient chez les cafetiers, un imposant dispositif de sécurité se déployait... Des barrières fleurissaient un peu partout, pour protéger des massifs de fleurs ou des ronds-points.

Bref, du pas net.

Et j'ai eu l'heureuse surprise de voir, dès le milieu de la journée d'hier, une foule impressionnante de gens, portant l'uniforme. Haut blanc. Bas blanc. Ici ou là, un foulard rouge ou une écharpe (rouge aussi) autour de la taille.

Et c'est alors que j'ai compris... Des profondeurs d'on-ne-sait-z'où, ont débarqué une horde d'une centaine de milliers de Pythonistas, parés pour un AFPYro historique !

Vers les 22h, une énorme pétarade a retenti, et la foule en liesse a célébré le sacre du roi Léon, en chantant :

Ah Léon, Léon, Léon, roi de Bayonne, roi de Bayonne
Ah Léon, Léon, Léon, roi de Bayonne, roi du Python !

On m'a même raconté que Frédéric Beigbeder, juché sur le balcon de l'hôtel de ville, aurait lancé vers la foule des clés (en carton). J'ignore la symbolique de ce geste, mais je gage qu'un internaute saura me renseigner.

Concernant l'accoutrement des pythonistes, j'ai eu quelques informations. J'ai pu en questionner quelques uns qui trinquaient en bas de chez moi : le blanc symbolise bien évidemment les espaces, la tabulation : bref, les blancs que les codeurs en Python utilisent pour indenter leur code ; puisque l'indentation fait partie de la syntaxe. Et comme c'est la couleur blanche qui est choisie, on oublie pour un temps les trolls sur le choix "tabulation ou espaces" et on célèbre ensemble la pureté et la beauté du code.

Concernant le foulard rouge, il y a plusieurs versions discordantes :

• Certains affirment que ce foulard a la couleur du rubis pour rendre hommage à cet autre langage de programmation : Ruby,
• D'autres évoquent les tests unitaires qu'on se doit d'écrire avant le code, la couleur rouge est un avertissement : un code non testé est un code défectueux !
• Pour un autre groupe, le rouge étant la couleur du communisme, c'est un hommage à notre bien aimé Dictateur Bénévole à Vie, Guido Van Rossum, qui guide notre communauté d'une main ferme vers la révolution Pythonnienne,
• D'autres encore évoquent le foulard porté par Karaté Kid. Mais cette version a peu de crédibilité.

Toujours est-il que pendant toute la nuit des milliers - que dis-je - des centaines de milliers de passionnés de Python ont célébré leur langage favori dans les rues de Bayonne. Oh franchement ça faisait plaisir à voir, toute cette joie et cette allégresse !

Allez Alleeeeeez, les petits doigts il va falloir pythonneeeeeeeeeer !

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).

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

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.

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

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.

3- Comment ça marche ?

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 :

4-Conclusion

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 …)

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.

Je suis allé à la présentation de "Une mise en place de l’eXtreme Programming" présenté par Karine Sabatier dans le cadre d'Agile Nantes. On y a parlé plutôt Ruby on Rails que python, mais surtout de méthodes agiles et XP.

Voici quelques points que j'ai retenu de cette présentation tout à fait pragmatique d'une mise en pratique des principes XP :

• Le principe de "Convention over configuration" : préférer la convention (notamment pour la programmation) plutôt que la contrainte par la configuration. Dans Ruby On Rails, les conventions sont très fortes, pour faire une application on ne peut pas s'éloigner du modèle MVC : les modèles sont dans "model", les views sont dans "views" etc... À ce sujet, la conférencière a fait référence à deux types de designs que je ne connaissait pas : le DDD Domain-driven Design et Behavior Driven Development.
• Utilisation de métaphores : trouver un langage commun avec le client mais aussi avec les utilisateurs
• Application de déploiement ruby on rails : Capistrano, bien qu'à Logilab nous privilégions le déploiement par paquets et dépôts debian, en python on pourra jeter un coup d'œil à Fabric.

• Leur projet XP utilisait le logiciel de gestion de projet Retrospectiva. Celui-ci ressemble sur bien des points à JPL (Jeux de Planification Logiciel) disponible sur le framework CubicWeb (http://www.cubicweb.org). Coté intégration continue : CruiseControl , en python nous privilégions apycot.
• Ce projet a essayé l'utilisation de Selenium pour ces tests web. Le constat est le même que chez Logilab : la première fois que ca marche c'est utile et apporte une grande satisfaction, dans un deuxième temps ca reste très difficile à maintenir. Nous regardons à présent plutôt du coté de Windmill qui a été intégré à la version 3.9 de cubicweb.
• Une mention a été fait d'une société fonctionnement uniquement en mode agile Pyxis.

Aide mémoire pour la confection d'un atelier logiciel autour de Python. Il sera complété au fur et à mesure...

Pré-requis :

• pip ; un sudo easy_install pip doit fonctionner si setuptools est installé.

Installation de Virtualenv & Virtualenvwrapper

Virtualenv permet de créer des environnements virtuels python avec les librairies de votre choix. Vous pouvez avoir un environnement virtuel pour chaque version de DJango (dj-096, dj-100, dj-110, dj-120, etc) et contre lesquels vous allez pouvoir tester l'application que vous développez. L'autre avantage est que l'on peut installer ce que l'on veut comme librairie python, sans avoir de droit système. De mémoire, on doit même pouvoir utiliser plusieurs versions de python si besoin. Bref, l'idéal pour des tests et ne pas pourrir son système global

Virtualenvwrapper est l'outil pour les fainéants qui utilisent virtualenv puisqu'il simplifie l'utilisation de virtualenv. Il y a des options assez sioux ; se reporter à la documentation

sudo pip install virtualenv virtualenvwrapper

Dans votre fichier $HOME/.bashrc :

# Création du répertoire accueillant les environnements virtuels
export WORKON_HOME=$HOME/python/virtualenv
# Instructions spécifiques pour l'usage de PIP
export PIP_VIRTUALENV_BASE=$WORKON_HOME
export PIP_RESPECT_VIRTUALENV=true
# Chargement des commandes fournies par virtualenvwrapper 
. /usr/bin/virtualenvwrapper.sh

Ensuite dans votre console :

# Création du répertoire accueillant les environnements virtuels
mkdir -p $HOME/python/virtualenv
# Prise en compte des modifications réalisées précédemments
source $HOME/.bashrc

avec pour résultat :

virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/initialize
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/premkvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postmkvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/prermvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postrmvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/predeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postdeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/preactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postactivate

Création de son premier environnement virtuel

mkvirtualenv demo
New python executable in demo/bin/python
Installing setuptools............done.
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/predeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/preactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/postactivate

Sur votre prompt, vous devez voir un petit (demo) apparaître indiquant que vous utilisez cet environnement :

Avant :

[nsteinmetz@citrouille ~]$

Après :

(demo)[nsteinmetz@citrouille ~]$ 

Comme tout projet doit avoir sa documentation et être versionné, installons sphinx et mercurial.

pip install sphinx mercurial

Il ne vous reste plus qu'à installer les autres librairies dont vous avez besoin.

Pour sortir de votre environnement, il suffit d'utiliser la commande deactivate.

Pour revenir dans votre environnement, il faut utiliser la commande workon :

• Si vous n'avez qu'un environnement virtuel (comme dans notre cas) alors vous basculez automatiquement dans cet environnement
• Si vous avez plusieurs environnements virtuels, alors workon liste les environnements disponibles. Pour en activer un en particulier, il faut préciser son nom ; dans notre cas workon demo.

To be continued... et je suis preneur de vos retours / idées / ...

Logilab est en ce moment en train d'acceuillir un sprint autour de la plateforme CubicWeb. L'objectif principal de ce sprint de 5 jours est d'améliorer l'usage de javascript et des css dans CubicWeb :

• avoir une API javascript propre, testée et documentée
• pouvoir facilement changer le style d'une application cubicweb
• gestion de bundle pour javascript et CSS
• une documentation sur les standards d'écriture des fichiers JS et CSS pour cubicweb

Ce sprint aura lieu du jeudi 29 avril 2010 au 5 mai 2010 (weekend exlus - les bureaux seront fermés). Vous êtes les bienvenus pour contribuer, filer un coup de main, faire du pair programming... ou simplement rencontrer des développeurs cubicweb. Vous pouvez même venir une après-midi ou une seule journée. Pour ceux avec des portables, il y aura du réseau disponible pour être connecté.

Adresse : 104 Boulevard Auguste-Blanqui, Paris. Sonnez à "Logilab".

Métro : St Jacques or Corvisart (Glacière est la station la plus proche mais sera fermée à partir de lundi)

Contact : http://www.logilab.fr/contact

Dates : du 29/04/2010 au 30/04/2010 et du 03/05/2010 au 05/05/2010

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 :

• à David bien entendu, parce que voilà, y aurait pas eu de djangocong sans david.
• à Samuel pour la vidéo et les bières belges, toujours aussi bonnes (je ne citerais pas de noms, même sous la torture (je dirais juste qu’il sait super bien manier un aspirateur), mais certains présents sont d’ailleurs tombés amoureux de certaines bières …)
• à Fred, pour avoir transporter son matos depuis la Belgique et nous avoir permis d’avoir des prises sons pour toutes les confs.
• à Laurent pour les photos, très réussies,
• à Johann qui oui a milité pour la création d’une asso, a réalisé de super tee-shirt dans un délai plus que court. (d’ailleurs il en reste quelqu’un à vendre, si vous voulez….)
• à Matthieu qui s’est occupé de tout plein de petits trucs tout le temps, quand on se demandait bien comment on allait faire, comme par exemple des badges (qui a remarqué que le poney django était en filigramme très clair sur la partie blanche des badges?), mais qui aussi passe l’aspirateur comme personne.
• À Daks pour avoir bossé sur le petit feuillet programme/info importantes et l’avoir imprimé en nombre.
• à la chérie de David qui a réalisé la mascotte des Congs
• à ma chérie qui m’a aidé sur les recherches de lieu (si vous avez eu des hotels où dormir, c’est grâce à elle ).
• à Marseille Innovation, le propriétaire des salles qui m’a fait confiance (bon j’ai du un peu jouer au chat de Shrek) et nous a permis d’avoir un événement gratuit en me prêtant les salles pour le week-end avec pour seule condition de ne rien dégrader et de les rendre aussi propre que ce que je les avais reçu.
• Aux généreux donateurs
• À tout les conférenciers pour avoir fait des conférences de qualité, vivantes, et carrément cools.
• À tout les présents, pour avoir été là, avoir donné la chance à cette première fois, avoir fait des centaines de kilomètre en train, voiture,  avions, vélos.
• à la météo de dimanche qui nous a permis de manger au soleil.

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à.

A l’année prochaine, pour de nouvelles aventures, qu’elles qu’en soient leur formes.

Les rencontres Django se sont achevées hier et il m'a fallu une bonne journée de récupération. Les premiers bilans de Laurent, Bruno, Nicolas, William, Boris et Olivier sont clairement positifs et ça me fait vraiment plaisir. Tout n'a pourtant pas été tout rose, enfin à part le poney ;-)

Bilan à chaud

Ce qui a fonctionné

• Le contenu des conférences : c'est pas évident de sélectionner des interventions qui plaisent à tout le monde mais c'était à mon avis un bon compromis sujets basiques/avancés.
• Les lightning talks : j'aurais préféré des sujets plus variés (moins Django-centrés) mais ça restait extrêmement intéressant et tout le monde a joué le jeu.
• La vidéo : bon j'attends de voir le résultat mais je n'ai aucun doute sur le perfectionnisme de Samuel !
• Les bières : je vais vous faire un aveu public, je n'aime pas la bière, mais la bière belge... c'est juste différent et pas pareil :-)
• La connexion : je doutais que ça tienne et finalement on a eu du net sur les deux jours de façon plutôt correcte.
• Plutôt satisfait de mon expérience avec EventBrite pour gérer les inscrits.

Ce qui n'a pas fonctionné

• Vouloir participer tout en organisant : c'était une erreur de vouloir cumuler les deux dans mon cas, à retenir.
• Les soirées : c'était pas non plus la cata mais tout le monde était bien crevé à chaque fois, il va falloir réfléchir à une autre organisation sur ce point.

Ce qui aurait pu être mieux

• Une meilleure gestion du temps : les confs étaient un poil trop longues à mon avis, je pense qu'un format 15 minutes + 5 minutes de questions aurait été plus dynamique et aurait permis de faire plus de pauses qui sont tout aussi intéressantes sur ce type de rendez-vous. La limite entre barcamp et conf traditionnelle reste encore à explorer...
• La préparation des repas : que ce soit samedi ou dimanche (en ayant réservé ou pas), on a pris une heure de retard et c'est pas normal. La solution budget plus conséquent et traiteur/livraison s'annonce incontournable.
• L'acoustique de la salle était un peu limite parfois et si on avait été plus nombreux un ampli aurait à mon avis été nécessaire.
• Quelques détails qui viendront avec l'expérience : réserver les viennoiseries, prévoir des jus, prévoir beaucoup de multi-prises, mieux baliser l'itinéraire, etc etc.

Bilan comptable

J'avais l'impression que l'on serait très « déficitaires » suite à l'achat des T-shirts mais finalement la balance est positive grâce notamment à un généreux don de dernière minute. Voici le bilan comptable final de l'événement, sachant que les salles étaient prêtées gracieusement :

Un événement gratuit de cette ampleur basé sur les dons reste donc réalisable. Je suis quand même légèrement déçu qu'il n'y ait eu « que » 46 personnes présentes alors que l'on était monté à 70 inscrits la quinzaine précédent l'événement, pour 57 inscrits le jour J suite aux désistements annoncés. Je ne sais pas si un prix, même symbolique, aurait limité ce phénomène. C'est une piste à réfléchir pour l'année prochaine.

Bilan motivation

Parlons justement de « la prochaine fois ». Il faut encore que l'on débriefe avec Jean-Michel mais a priori les nombreux messages sur Twitter et sur les blogs sont très encourageants et motivants. Je ne vous cache pas que c'est une grande source de satisfaction personnelle.

Quelques pistes :

• Rester aussi « artisanal » et se faire plaisir entre geeks, modulo les améliorations proposées.
• Passer à la vitesse supérieure et accueillir EuroDjangoCon.
• Davantage profiter du lieu en organisant une session sur une semaine, dans le style de /dev/fort en effectifs réduits avec bronzette et code au programme.
• Faire un DjangoSea, pendant à DjangoSki.

L'avantage de ces propositions étant qu'elles sont non exclusives ;-).

Bilan remerciements

Déjà merci à tous d'être venu(e)s, parfois de loin : Toulouse, Bayonne, Rennes, Angleterre, Belgique, Suisse, Grenoble, Nice, ça fait quand même une belle boucle !

Merci aux conférenciers d'avoir été consciencieux dans la préparation de leur intervention.

Merci à Laurent pour les photos des intervenants.

Merci à Samuel pour la vidéo pendant les deux jours et l'importation de bières ;-). Je sais combien la tâche de synchro/correction/encodage/etc des vidéos va être fastidieuse, courage !

Merci à Frédéric pour le son pendant les deux jours aussi, je suis impatient de voir le résultat.

Merci à Johan pour nous avoir motivés à créer une association et pour avoir imprimé les T-shirts en un temps record !

Merci à Mathieu pour toutes ses petites attentions qui font gagner un temps fou.

Merci à Jean-Michel sans qui rien n'aurait été possible.

Merci à la miss d'avoir dessiné un Django pony marseillais et d'avoir donné les droits de paternité à l'événement.

Merci aux généreux donateurs et aux rédacteurs du compte-rendu collaboratif. J'intégrerai ces notes sur le site la semaine prochaine.

Ai fait hier une conférence sur Beeroverip lors des premières rencontres Django francophones, dans la belle ville de Marseille.

Je publie ici les slides de la conférence, qui devrait être disponible en vidéo bientôt.

L'événement se passe ma foi à merveille : super orga, très très bonnes confs (et je ne dis pas ça pour flatter, je suis vraiment bluffé par la grande diversité et qualité des orateurs). Et une excellente ambiance, entre une bande de copains de l'IRC qui arrivent à mettre un visage et une voix sur des pseudos.

Python is love, my friends.

0. Tu te trouves sur ce blog. Un nouvel article est apparu depuis ta dernière visite. Si tu veux le lire, vas en 1.. Si tu ne veux pas le lire, tu vas en 8.

1. L'article en question relate un site qui parle de jeux de rôles. Si tu sais ce qu'est un jeu de rôle, vas en 3. Si tu ne sais pas, vas en 6.

2. Sache donc qu'il existe un nouveau site de jeux de rôles. Ce site s'appelle "Histoires de Rôlistes". Il offre aux rôlistes (ceux qui pratiquent ce genre de jeu) de raconter leurs histoires, leurs éclats de rire, leurs bon ou mauvais souvenirs concernant une partie ou un personnage. Si tu as des histoires à raconter, tu peux aller en 4. Sinon, tu peux aller en 5.

3. Si tu as déjà joué à jeu de rôle et que ça t'a plu, vas en 2. Si tu n'a jamais joué à un jeu de rôle d'aventure fantastique ou que tu y as joué et que tu n'as pas aimé, vas en 8.

4. Il est très facile de s'inscrire sur le site et de proposer une histoire.

5. Rien ne t'empêche d'aller lire les histoires sur le site. Certaines sont assez cryptiques, d'autres peuvent être comprises, même par quelqu'un qui n'a jamais joué à un de ces jeux en particulier. Et même un utilisateur "passif" peut participer à sa façon, en mettant un commentaire, on signalant qu'il aime l'histoire en question, etc. Il y a même un système de badges qui récompense certaines pratiques sur le site. À présent, si cet article t'a plu, tu peux aller en 7. Sinon, tu peux aller en 8.

6. Un jeu de rôle est une sorte de jeu dans lequel des joueurs incarnent des personnages imaginaires qui doivent survivre aux situations présentées par le Maître de jeu. Personnellement, je définis ce jeu par : "c'est une pièce de théâtre pour laquelle les comédiens ne connaissent pas le scénario à l'avance". Wikipedia possède un article pas trop mal détaillé. Maintenant que tu sais à peu près ce qu'est un jeu de rôle, tu peux aller en 3.

7. Oui, bon, certes, c'est pas l'article le plus remarquable de la blogophonie, non plus, faut pas exagérer. Bon, allez, fiche le camp. Hop ! Je te libère, tu peux y allez, maintenant.

8. Un énorme troll qui respire bruyamment abat une énorme massue dans ta tête. Ton crâne s'enfonce entre tes épaules. Tu es mort. S'il fallait une consolation à ta mort soudaine, ce serait que le site est propulsé par Django.

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.

1- La genèse, installation et création du projet.

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.

• Le premier ne sert à rien, c’est simplement la liste des options en fonction de si on a un abonnement payant ou pas.
• L’onglet Edit sert un peu plus, il permet de modifier les infos que l’on a saisit à la création du projet
• Enfin Test & Package sera celui sur lequel vous allez passer le plus de temps, vu que c’est à partir de là que vous lancerez votre projet. (et qu’un jour quand il sera fini vous le packagerait et tout et tout)

2- Et ensuite ?

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.

3- Et TwittPouick naquit.

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.

3.1 Récupération de sa timeline.

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.

3.2 Affichage de 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.

3.3 Utilisation des API Titanium

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.

4- Conclusion.

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.

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.

‘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 :

• j’ai eu l’idée du site en juillet 2009, j’ai aussitôt acheté le nom de domaine
• j’ai commencé à aligner quelques lignes de code en aout (merci les vacances), mais ayant du boulot du boulot, en retard, j’ai que très peu avancé.
• Je m’y suis vraiment mis fin janvier/début février en essayant de trouver du temps la nuit et les week-ends.
• le week-end de Pâques m’a permis de finaliser le tout et de faire tester à quelques chanceux (merci les gens de #djangocong et du plug).

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.

Voilà quelques temps que je fais mumuse avec les bases de données orientées document (du style Couchdb et/ou MongoDb). Pour CouchDb, son intégration est déjà incluse dans Karmic Koala pour la bonne raison qu'Ubuntu One s'appuie sur Couch.

En attendant que Mongodb débarque dans les dépôts officiels de Lucid, on peut toujours utiliser les dépôts tiers. Et quand bien même on serait arrivés dans l'ère du Lynx, utiliser ces dépôts permet d'utiliser une version plus récente que celle proposée dans les dépôts d'Ubuntu.

En terme de dépôt tiers, c'est un peu le top, puisque ce sont des dépôts fournis par 10gen (les développeurs à l'origine du projet). Pour ce faire, tutorial très simple.

ATTENTION !!! Installer des logiciels en-dehors des dépôts officiels peut mettre en péril la stabilité de ton système. Il est indispensable que tu saches parfaitement ce que tu fais avant de poursuivre.

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 :

• /feeds/latest
• /feeds/categories

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 :

• KeyDict_title.html
• KeyDict_description.html

Soit dans notre exemple :

• latest_title.html
• latest_description.html
• categories_title.html
• categories_description.html

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).

1- Les méthodes qui renvoient un queryset (ou assimilés)

annotate(*args, **kwargs)

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 :

values(*fields) et Values_list (*fields)

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)

A quoi sert values et values_list ?

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.

defer (*fields)

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.

only (*fields)

C’est l’inverse du defer, on ne récupère que certains champs.

2- Les fonctions qui ne renvoient pas un queryset.

in_bulk(id_list)

Cette petite fonction bien sympa prend une liste de pk et renvoie un dico des objets qui correspondent (les clés étant les pk)

latest(field_name=None)

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.

aggregate(*args, **kwargs)

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.

exists()

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 ).

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.