Donc, pour la troisième année les Djangocongs ont lieu, à nouveau dans le sud. Mais cette année ce ne sera pas à Marseille (après tout il faut bien vous faire découvrir de nouvelles villes) mais à Montpellier pendant le week end du 14-15 avril.

Du coup, le staff s’élargit et accueille :

• des locaux (nico et stéphane pour ne pas les nommer), véritables supermens de l’organisation, qui avec l’agilité qui les caractérisent s’occupent de tout et du reste. (Enfin c’est tout de même moi qui continue à faire les factures que les gentils sponsors vont recevoir, des sousssssss)

• pleins de bonnes volontés, qui ont décidés que pour la troisième, il était temps de montrer qu’eux aussi avait des biscottos sous le tee-shirt geek et ont très gentiment proposés leur aide.

Un staff élargi qui se retrousse les manches pour que cette troisième édition soit plus qu’un succès, soit une apothéose.

Et pour cela, plusieurs choses :

• la retour du découpage en quatre temps, avec simplement quelques arrangement pour parfaire le tout
• une unité de lieu, … enfin.
• Un lieu juste magique,.. les pieds dans l’eau, au bords de la plage, l’eau turquoise, les palmiers, le ciel bleu, le sable fin (et si il pleut ça sera à cause des nordistes).

Mais pour que cette troisième édition soit vraiment une édition mémorable, une édition totalement gaga, il va falloir que toi, cher lecteur, tu y mettes un peu du tien. Bien sur il faudra t’inscrire, des que cela sera possible (mais ne t’inquiète pas, tu seras au courant). Bien sur il faudra ne pas oublier de prendre tes billets de train, ton ordi et ton maillot starwars.

Mais vous pouvez faire plus . Pour cela rien de plus simple,  il va falloir prendre son courage ponifique à deux mains et proposer un sujet de conférence (ATTENTION, tu n’as que jusqu’au 13 janvier). Vous ne savez pas de quoi parler ? Vous avez l’impression de ne rien avoir à dire ? Si vous utilisez django, vous vous trompez sûrement. Je suis sur que vous avez un retour d’expérience enrichissant pour tous et que vous allez pouvoir partager en douze minutes. Vous avez utilisé django dans un contexte non web, fait des zigouigouis avec HTML5 ou de la haute dispo, lancé le dev d’un module utilisé par la terre entière et vous avez du coup une vraie expérience de lead de projet avec des utilisateurs ??? Vous voyez que vous en avez des choses à nous apprendre.

Vous ne vous reconnaissez dans aucune des phrases du dessus ? C’est pas grave, vous avez sûrement autre chose à nous raconter. Et en plus, comme on est conciliant, si vous avez peur que douze minutes cela soit trop pour vous, si vous êtes plus du genre 5 minutes douche comprise, alors vous allez être aux anges. Parce que vous aller pouvoir candidater pour un LT de 5 minutes. Le monde est bien fait non ?

Et si vraiment, vraiment tu penses que cette année, non, tu ne peux proposer un sujet, ce n’est pas grave. Après avoir passé une bonne demi journée à apprendre en écoutant des conférences qui seront, forcément, super intéressantes tu pourras participer jusqu’à plus soif (non je parle pas de l’apéro…) lors des sessions de barcamp et de sprint. Sans oublier la dernière demi journée qui te permettra de faire le fou sur la plage (ou tout autre activité ne nécessitant pas de haut de forme).

Plus que 150 jours ….

Ps : pour ceux qui n’ont pas reconnu la référence du titre : www.youtube.com/watch?v=lxn48wSiCzg
Ps2 : merci à stéphane de m’avoir fait découvrir Mari Kasurinen

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

Deux possibilités pour le trouver, sur sa page github (on regrettera le choix de github et non bitbucket mais bon:) )  ou sur sa page pypi. Ce qui du coup vous permettra de l’installer de deux façon :

• un petit git clone bien de chez nous
• un simple : pip install django-ratelimit-backend

La doc est dispo sur la page readthedocs du projet. Et elle est bien fournie. Une aide à l’install, un quickstart et une section pour expliquer comment modifier le critère de limitation et une référence complète du code.

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

A empêcher les vilains méchants pas beau de crier ‘des logins ou un sort’ devant vos jolis sites webs Django. En clair, à ‘bannir’ pendant 5 minutes des IP qui auraient tentées de se logguer sur votre appli à de trop nombreuses reprises.
Les réglages de base sont :

• si tu tentes de te logguer 30 fois sans y arriver
• dans une période de moins de 5 minutes
• alors tu es bannis 5 minutes.

3- Comment ça marche ?

C’est relativement facile.
Première chose, il n’est même pas nécessaire d’ajouter l’app dans vos INSTALLED_APPS, à part si vous voulez lancer les tests (vous pourrez alors installer tox si vous voulez tester avec toutes les versions de django)

Il vous faudra par contre ajouter un backend d’authentification à savoir :  ‘ratelimitbackend.backends.RateLimitModelBackend’.

Il vous faudra de plus :

• utiliser la vue ratelimitbackend.views.login à la place de django.contrib.auth.views.login
• si vous utilisez l’admin, utiliser ratelimitbackend. admin au lieu de l’admin normal de django.
• Ajouter le middleware ratelimitbackend.middleware.RateLimitMiddleware

Vous pourrez bien entendu modifier les critères de détection de vilains. Pour cela il vous suffira d’implémenter votre propre middleware (tout est bien expliqué dans la doc, ne paniquez pas!)

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

Où est ce qu’on le trouve, sur son site web, sa page pypi et sa page github.

Pour l’installer, vous aurez plusieurs plusieurs solutions :

• un git clone tout simple
• un petit pip install en utilisant le support git de pip
• un petit easy_install ( ou pip install normal) pour avoir la dernière version stable.

Niveau démo, il existe et c’est carrément cool :

• une démo du rendu (qui sert à héberger la doc)
• une démo de la version d’administration.
• Un planet qui liste tous les blogs utilisant Zinnia

Concernant la doc, elle est vraiment super bien foutue et très complète. Installation, Configuration, Configuration avancée, extensibilité, etc etc … C’est vraiment une des meilleures docs d’application django que j’ai pu lire. Pour ne pas dire la meilleure d’ailleurs.

Cerise sur le gâteau, on peut même voir la couverture de code des tests.

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

Bon, je l’ai dit c’est un moteur de blog. Donc on a des catégories, des billets, des tags, et des flux RSS.

Mais ce n’est pas tout, Zinnia propose vraiment pas mal de petites fonctionnalités qui en font un vrai moteur de blog, qui (et je le dis sincèrement) peut imaginer concurrencer certains moteurs de blogs php très connus.

Zinnia offre par exemple :

• des url shortenners
• de la publication de tweets automatique sur publication d’article
• un moteur de recherche interne
• détection des spams avec askimet (ou autre)
• des sitemap
• des channels, un truc spécifique à Zinnia
• une extension facile, ….

Et si vous avez déjà un blog ? Genre WordPress ou Blogger ?

Et ben Zinnia offre des moulinettes d’import / export. Et ça, c’est vraiment terrible.

3- Bon et en conclusion ?

Il y a a mon sens plein de bonnes idées dans Zinnia :

• Les script d’import / export sont tout simplement un must have qui vont que l’on peut vraiment imaginer migrer un blog existant sous Zinnia.
• Les channels qui permettent de réutiliser le moteur de recherche interne (qui utilise pyparsing) pour faire des recherches parmis les articles et en sortir une partie.
• Les models qui sont bien fait, à base de classe abstract et permettent de surcharger sans difficulté les choses.
• Il utilise south ce qui doit faciliter les migrations.

A tout cela il faut ajouter le fait qu’il n’y est au final que peu de dépendances. Au niveau des apps django, il n’y a que deux dépendances obligatoires :

• django-mptt
• django-tagging

Après cela dépends des fonctionnalités que vous voulez mettre en place, mais cela reste très light et très clair. (je ne parlerais pas par exemple de pinax qui en comparaison me fait l’effet d’une usine à gaz).

Je vais donc suivre ce projet avec intérêt et même si je ne suis pas sur de passer tout de suite le mad blog en Zinnia, je vais en migrer d’autre d’ici quelques temps, ça, c’est certain.

Espérons que la django app du mois d’aout soit à l’heure…. En attendant de voir si en août, à l’heure je serais, je vous propose de découvrir cette petite django-app bien sympatique.

Mais avant un peu de contexte. Je cherche depuis quelques temps une django app pour faire de l’autocompletion. Djangopackages qui est décidément très souvent mon ami propose un tableau récapitulatif assez sympa d’un certain nombre d’app qui propose cela.

Parmi la liste, j’ai décidé de tester django-autocomplete qui me paraissait le mieux répondre à mes besoin, à savoir de l’autocomplete facile coté admin, comme coté site non admin.

Nouveauté ce mois si au niveau du billet, je vais vous présenter deux versions de l’app à savoir la version ‘officielle’ faite par tyrion et un fork fait par etienned. Pourquoi vous présentez deux versions ? Parce que la version d’etienned propose quelques améliorations visuelles intéressantes (et quelques petits refactor pas débiles).

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

Ici cela dépends de la version que vous désirez tester de django-autocomplete. Si vous voulez tester la version première de tyrion alors vous avez  deux possibilité :

• par un petit hg clone à partir de sa page bitbucket
• en utilisant easy_install ou pip.

Par contre pour la version d’etienned, pas de package, donc pas d’easy_install ou de pip, il n’y a qu’une solution, un bon vieux hg clone

Chose suffisamment rare pour qu’elle soit mis en avant, il y a une démo de la version première, que vous pourrez tester ici.

Concernant la doc, pour les deux versions, tout se trouve dans bitbucket.

• Dans la version de tyrion vous aurez droit au fichier Readme et au wiki.
• Dans la version d’etienned il n’y a que le fichier Readme qui est composé en grande partie du descriptif des addons que propose ce fork (et qui se finit par un exemple d’utilisation dans l’admin).

Est ce que c’est suffisant ? Si vous envisagez de n’utiliser l’autocomplétion que dans la partie admin, clairement oui. Sinon alors là, clairement non. Vraiment pas même. Et à vous les joies de la lecture du code source pour comprendre comment cela fonctionne (ou alors vous pouvez continuer à lire mon billet et voir comment tout cela fonctionne dans la partie 3 ).

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

Tout simplement à proposer un mécanisme d’autocomplétion sur les champs texte ou Int mais aussi  les foreignkey et les manytomany. Et qui, cerise sur le gâteau, ce veut simple au niveau de son déploiement

Et à le faire d’une façon un peu ‘magique’. On déclare seulement quels sont les models qui mettront en place l’autocomplétion et pour lesquels de leur champs. Et après tout ce fait presque tout seul (en tout cas pour la mise en place des urls qui permettent de retourner le résultat du filtrage en fonction des caractères tapés, c’est tout automatique).

3- Comment ça marche ?

C’est presque tout simple.  En tout cas si vous voulez intégrer django-autcomplete dans l’admin.

Imaginons que vous vouliez autocomplete les auteurs de bouquin dans une app de critique de livre.

Vous allez commencer par déclarer une classe qui configure votre autocomplete :

Ensuite ?

Vous déclarez simplement où vous voulez utiliser votre autocomplete. En partant du principe que votre model pour les reviews de bouquin s’appelle Reviews et que le champ pour l’autheur du bouquin s’appelle book_author cela donnera cela :

et voilà. C’est fini. Vous avez dans votre admin, un champ ForeignKey en autocomplétion. Et sans forcer.

En lisant la doc vous verrez que l’on peut faire de façon différente, spécifier le queryset sur lequel on veut limiter l’autocomplete, etc etc …

Maintenant, qu’est ce qui se passe si vous voulez mettre un peu d’autocomplétion dans votre site version pas admin ?

Hum ben là, c’est pas beaucoup plus compliqué en fait. Le problème est juste qu’il n’existe pas de doc.
Mais si vous farfouillez dans le code vous verrez qu’il existe une classe de widget (AutocompleteWidget qui se trouve dans  autocomplete.widgets qui permet de mettre en place l’autocomplétion).

Il vous suffit alors dans votre formulaire, de rajouter le paramêtre widget à votre Field et de lui passer un AutocompleteWidget (qui a lui même en paramètre le champ qui mettra en place l’autocomplétion).

Si l’on reprend l’exemple d’au dessus on pourrait avoir quelque chose ressemblant à cela :

Il y a bien évidement le widget qui va bien pour la version multiple sélection (MultipleAutocompleteWidget)

Et si l’on continue à fouiller un peu plus, dans utils, on trouvera une très sympathique autocompleteform_factory qui permet de générer un form en prenant un paramètre le Model qui va bien, un dictionnaire listant les champs implémentant l’autocomplétion
ainsi que les champs à exclure.

4 conclusion et tips.

J’ai eu quelques problèmes lors de mes tests lorsque j’ai voulu installer django-autocomplete en temps qu’app dans le répertoire de mon projet et pas dans mon pythonpath. J’avais des phénomènes bizarre de double exécution de code qui me donnais de jolies exception. Je n’ai pas vraiment réussi à comprendre le pourquoi du comment ni pourquoi en sortant simplement l’app du répertoire de mon projet cela se mettait à fonctionner parfaitement…

Pour ceux qui utilisent grappeli, je viens de voir qu’il existait un fork de django-autocomplete pour en faciliter l’intégration. Mais par contre, là, je n’ai pas du tout essayé.

Ha et pour finir, le titre est une référence un peu obscure à un film avec Jack Black:).

Ce mois-ci, enfin le mois dernier, je vais vous présenter Impostor une application que j’ai découvert au détour d’un tweet (de dzen je crois )

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

Deux possibilité pour le trouver, sa page github ou sa page django packages. Pas de page pypi, enfin pas encore, espérons qu’elle arrive vite.

Pour l’installer, pas le choix, il faut passer par github.
Un petit git clone https://github.com/samastur/Impostor.git et c’est plié.

Quand à la doc, Elle se limite au readme.rst. Mais cela suffit. Et puis le readme est bien clair. Il vous expliquera comment l’installer dans votre projet django et comment vous en servir (et puis si vous continuer à lire, je vous l’expliquerais aussi)

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

Tout simplement à se déguiser lorsque l’on se logue. D’ailleurs c’est un des meilleurs noms d’app django que j’ai pu croiser. Décrivant à la fois bien la finalité de l’app tout en étant rigolo.

Impostor vous permettra donc, si vous avez un login staff member de vous loguer en temps qu’un au tre utilisateur. Vous verrez donc l’appli comme il la voit, vous pourrez interagir avec django en étant considéré comme l’utilisateur dont vous avez prit les traits (enfin le login).

3- Comment ça marche ?

C’est tout simple.
Il suffit d’ajouter un backend d’authentification à votre application django, à savoir ‘impostor.backend.AuthBackend’

ce qui doit vous donner quelque chose ressemblant à :

 AUTHENTICATION_BACKENDS = (
 'django.contrib.auth.backends.ModelBackend',
 'impostor.backend.AuthBackend',
 )

et bien entendu il faut ajouter ‘impostor’ à vos INSTALLED_APPS

Ensuite ?

Un simple petit syncdb et c’est fini, vous allez pouvoir vous déguiser en un de vos utilisateurs. Comment ?
Au lieu de vous loguer avec votre login il vous suffira de vous loguer ainsi :

 votrelogin as leloginquevousvoulezdevenir

et de taper votre password.

Donc la deuxième django app du mois sera django-urlcrypt. Une petite précision avant d’aller plus loin, c’est une des toutes premières fois où je vais parler d’une app sans avoir fait plus que la tester sur un projet de test, sans avoir d’idée précise de où ni comment je vais l’utiliser ‘en vrai’.

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

Alors on le trouve soit sur sa page pypi soit sur sa page github.

Pour l’installation là encore, les trois moyens habituels :

• par easy_install
• pip
• un petit git clone des familles

La doc, là c’est comme l’app précédente, elle est limitée au contenu de la page de pypi ou au fichier Readme.rst.

Bon alors c’est vrai que la doc est suffisante pour comprendre comment l’app marche, mais sur une app qui est aussi ‘sensible’, une bonne lecture du code ne fait pas de mal (c’est d’ailleurs ce que j’ai fait quand j’ai commencé à faire joujou avec).

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

En fait l’app a deux utilité même si une seule est vraiment mise en avant sur la doc de l’app. La première c’est de fournir aux utilisateurs une url ressemblant à ça :  http://www.mydomain.com/r/TkNJBkNFAghDWkdFGPUAQEfcDUJfEBIREgEUFl1BQ18IQkdDUUcPSh4ADAYAWhYKHh8KHBsHEw qui les authentifiera automatiquement et qui en plus les redirigera vers l’url que vous aurez voulu.  (genre le renvoyer sur /profil ou /inbox)

L’autre fonctionnalité moins mise en avant, c’est que l’on peut encoder des infos dans l’url, dans un message qui se trouve être un dictionnaire. Alors honnêtement je ne sais pas trop encore à quoi cela peut servir, mais je trouve l’idée coolos.

3- Comment ça marche ?

C’est tout simple.

Dans une vue, on peut utiliser la fonction urlcrypt.generate_login_token qui prend en param l’utilisateur et l’url de redirect et qui génére le token qui encode le tout. Ensuite il suffit de créer l’url complète qui va bien.

Dans un template, on utilise le template tags encoded_url qui prend comme argument un user et une url de redirect.

Enfin on peut utiliser les fonctions urlcrypt.encode_token et urlcrypt.decode_token
qui permettront de crypter / décrypter un message contenu dans un dictionnaire (voir l’aide pour plus d’infos).

Au niveau des configurations possibles, on peut configurer :

• à combien de requêtes à droit un visiteur
• l’url de fallblack si l’authentification contenu dans l’url echoue
• un path vers une clé privée RSA qui permettra d’ajouter un cryptage RSA lorsque l’on génère le token.  L’utilisation de ce paramètre est très très fortement recommandé (pour rappel pour généré le clé : ssh-keygen -t rsa -f )

4- conclusion

Le mécanisme de login par url cryptée me séduit beaucoup. Mais d’un autre coté je me pose des questions au niveau sécurité. Parce que l’url, l’utilisateur il va devoir la stocker. Et qu’autant mémoriser un mot de passe, on peut le faire, autant apprendre une url…, qu’en pensez vous ?

La question de la durée de vie de l’url me semble aussi importante. J’aurais aimé avoir dans l’app un système qui permette de rendre des url obsolètes parce que trop vieilles..

Enfin concernant la deuxième méthode d’utilisation, à savoir encoder des messages dans l’url, je trouve l’idée ravissante, j’ai envie de l’utiliser mais je ne sais pas à quoi elle pourrait bien me servir. A réfléchir donc.

UPDATE:

on vient de me pointer quelques problèmes qui existent avec cette app (discussion visible ici) Apparement un des problèmes a été réglé en utilisant RSA (mais son utilisation n’est toujours pas obligatoire) mais il me semble que le hash du password est toujours utilisé dans certain cas. Ce qui n’est vraiment pas une bonne idée. En l’état l’app n’est donc pas forcément à utiliser, mais plutôt à étudier pour imaginer son propre système.

Du coup, pour marquer, le coup, je publierais deux django app du mois de mai, même si je les publie en juin.

Et pour commencer, django-countries. C’est d’ailleurs assez rigolo parce que je parlais il y a peu de moyen de gérer les pays, avec une liste de choix existantes, etc.. et op, je tombe sur django-countries.

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

Vous trouverez django-countries soit sur sa page pypi soit sur sa page bitbucket.

Pour l’installation, vous avez les trois moyens désormais classique :

• un easy_install
• un pip install
• un bon vieux hg clone

La doc elle se limite à :

• la page pypi
• le readme du repository

Sachant que dans les deux cas, le contenu est le même. Mais vu la simplicité de l’app, cela suffit amplement.

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

L’app rajoute tout simplement un nouveau type de field, le CountryField. Ce CountryField vous permettra de gérer les codes à 2 lettres internationaux qui modélisent les pays mais aussi d’afficher un petit gif du drapeau qui va bien.

Et oui, comme dans les vrais sites et tout quoi.

3- Comment ça marche ?

C’est donc vraiment tout couillon. Un field CountryField. Et des instances de fiels qui ont les données membre :

• code (le code à deux lettres)
• name (le vrai nom du pays)
• flag (le chemin vers le drapeau)

Rien de bien compliqué.

Après avoir passé quelques heures à farfouiller dans la doc et à faire quelques tests, je me suis dit qu’il n’y avait pas de raisons que je garde mes découvertes pour moi.

Voici donc un premier billet pour partager les plus utiles avec vous.

list_display, comment changer l’entête d’une colonne fonction.

On sait tous comment configurer les colonnes que l’on va afficher dans la vue en liste des content_type. En utilisant list_display. Mais est ce que cela ne vous ai jamais arrivé de vouloir afficher le résultat d’une fonction ?

Aucun problème, il suffit de mettre le nom de la fonction dans list_display. Oui c’est vrai, sauf que.. sauf que l’entête de colonne c’est le nom de la fonction.. Et ça, ce n’est pas très joli.

Sauf que, sauf que django pense à tout. Pour pouvoir afficher un intitulé de colonne sympa au lieu du nom de la fonction, il suffit de rajouter à votre fonction un attribut short_description qui contiendra l’intitulé voulu.

Un petit exemple :

list_display, comment utiliser du HTML dans les colonnes .

De même, il se peut que votre super fonction qui tue, renvoie non pas une valeur simple (genre un nombre) mais du code html (que vous aurez bien entendu généré avec un template). Sauf que là, oh rage, oh désespoir. Vous avez beau faire tout les mark_safe du monde, rien n’y fait. Votre code est escaped…

Comment modifier ça ? La encore, ça passe par un attribut de fonction, allow_tags qu’il vous suffira de mettre à True. Et miracle, ça fonctionne.

Et en plus, ce qui est bien, c’est que comme c’est une toute petite app, ça ne sera pas fatiguant du tout d’écrire ce billet.

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

Là c’est tout simple, on la trouve sur github. Et uniquement sur github. Quand à la doc elle tient toute entière dans le fichier Readme.rst qui se trouve lui aussi sur github. (et vous la trouverez aussi en docstring de l’unique classe que contient l’app).

Pour l’installation il suffit ou plutôt il faut forcément, cloner le repo github.

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

A gérer d’une manière propre les Choices que l’on peut avoir à mettre en place dans les fields Django.  Parce qu’il est vrai que la méthode normale, à base de constantes que l’on ne sait pas trop où déclarer et de tuples de tuples, me si elle fonctionne bien, n’est pas super élégante.

L’app permet donc d’encapsuler tout ça dans une belle petite classe

3- Comment ça marche ?

Bon la je vais, sans aucun remords, faire un petit copié/collé de la doc. Parce que l’explication de comment ça marche est très bien faite.

Donc en fait cela marche comme ça :

plutôt clair non ?

Et cela remplace ce code là :

Personnellement, je trouve que la notation pointée  STATES.CHOICES ou  STATES.DRAFT est bien bien plus clair que la notation précédente.

Conclusion

Une petite app qui ne fait qu’une chose mais qui le fait bien. A utiliser de partout donc. (Il ne manque juste que des tests ..:) ) .

Les Congs en quelques chiffres :

• 11 conférences le matin
• 12 slots de barcamp l’après-midi
• 1 app releasée durant les Congs
• 1 doc de bonne pratique lancée
• 75 personnes le samedi matin dans l’amphi, à écouter les conférences (un peu moins le dimanche matin, après la soirée arrosée, parce que comme là dit un illustre inconnu : ‘ce matin, on a 50% de perte)
• 3 repas complétement pris en charge par l’organisation
• un peu plus de 100 dosettes de Senseo utilisés sur les deux jours (mais qu’une dizaine de sachet de thé, on le sait tous, le café est supérieur au thé)
• 200 litres d’eau bus, au bas mot, parce que dans le sud, il fait chaud, Cong !
• Quelques bonnes dizaines de coup de soleil, cadeau surprise pour ceux qui n’ont pas l’habitude du vrai soleil du vrai sud.
• 36 litres de bières (edit : j’avais oublié les 6litres de guinness) et 20 litres de vin bu lors des 6h qu’à durer la soirée du samedi soir. Et pourtant tout le monde est rentré sur ses jambes.
• Un nombre de kilo de paella engloutis par nos estomacs,  qui fait juste peur. Comme quoi les poneys, ils ont bon appétit.
• un article dans Linux Magazine dans le prochain numéro.

Les Congs du point de vue d’un organisateur.

La deuxième édition fut l’occasion d’essayer d’être plus pro dans l’organisation des choses. Et je pense qu’on a fait plus qu’essayer.

• Plus de salles dont un amphi bien équipé niveau son (Merci encore à l’école centrale de Marseille nous avoir accueilli pendant ces deux jours).
• Plus de préparation au niveau des repas. On a remplacé les réservations dans de multiples restos par des plateaux repas et des sandwitch livrés sur site, pour gagner du temps et permettre de continuer en mangeant les discussions entamées pendant les confs.
• Une vrai préparation pour la soirée du samedi (à la Boate) et pas juste un ‘on va sur le vieux port et on trouve un resto comme l’année dernière).
• Quelques choix un peu clivant comme des durées de conf courtes ou du #Nowificonf pendant une partie des Congs.
• Moins de trajet dans ma voiture pour chercher les gens perdus ou les ramener. Marseille commence à priori à être connu de tous et il n’y a plus de femme enceinte parmi les présentes .
• Encore plein de points à parfaire ou à juste faire (comme prévoir l’impression des badges en avance et les donner le premier matin, à l’arrivée. Ou prévoir un vrai carnet de route de l’accompagnant avec activités et truc à faire pour ne pas lâcher les gens comme ça et qu’ils s’ennuient pendant deux jours).

Les congs d’un point de vue perso.

Vivement la troisième édition. Comme les deux premières fois, la fin des Congs arrivant, un grand sentiment de vide se fait sentir et à peine le dimanche soir arrivé, l’envie d’être déjà à l’année prochaine, de pouvoir discuter à nouveau en IRL avec des gens que je ne vois parfois qu’une fois par an.
D’un point de vue perso, l’année dernière avait été une grande claque technique dans ma figure. Deux jours de conférences non stop, ça en met plein les mirettes.
Cette année, malgré le fait qu’il y est moins de conférences ce fut encore mieux. Les confs auxquelles j’ai pu assister m’ont en effet fait découvrir plein d’outil qu’il va falloir que je test, mais les barcamps ont permis d’échanger pour de vrai, de commencer même pour certaines sessions à poser les premières pierres de quelques choses (je pense là a Geek sans Frontière par exemple).

Mais ce n’est pas tout. L’un des points qui fait que cette deuxième édition fut immensément mieux que la première c’est que cette année la partie ‘non technique’ a été pensée et organisée. Et autant sur des découvertes techniques, on peut imaginer les faire par IRC / billets de blog, autant rencontrer les gens et se rendre compte qu’on les apprécie, pour de vrai, hé ben, y a pas à dire, il faut être dans la même pièce.

On mange difficilement de la barbe à papa rose sur IRC. Apprendre le GO, c’est aussi un peu compliqué. Et je ne parlerais même pas de jouer à ‘il était une fois’ avec Kael, Cyberj et Exirel. Ou de tenter de survivre à une partie de Pandémie. Et comme ArmagnacOverIP n’existe pas encore, on a encore besoin que dzen ramène sa bouteille dans son sac pour y gouter (je ne t’oublie pas brutasse, ta chartreuse était très bonne aussi:) ). C’est tout ces moments là. Tout ces moments partagés qui font que pour de vrai, DjangoCong 2.0, putaing, c’était terrible.

Et à l’année prochaine, pour d’autre aventure et une djangoCong 3.0

quelques liens :

• le convore des articles de blog qui parlent des Congs
• le convore des slides des confs
• le groupe djangofr sur linkedin
• l’etherpad de debrief collaboratif

django-generic-aggregation

Qui n’a jamais utilisé les agrégat dans Django ? C’est quand même super utile. Et qui n’a pas ralé sur le fait que zut alors… Saperlipopette même, on ne pouvait pas utiliser les agrégat sur les Generic FK ?

Et c’est là qu’arrive django-generic-aggregation. Qui permet justement de le faire.

Concernant l’installation, trois moyens :

• easy_install
• pip
• un petit git des famille grâce à github : https://github.com/coleifer/django-generic-aggregation

Quand à la doc, vous aurez droit à la page de pypi qui est aussi la page de doc de github. Bon après, il faut bien dire que l’app n’est pas super compliqué à comprendre.

Et au pire, il y a le code des tests. Une petite précision toutefois concernant la doc, la page readthedoc de l’app renvoie pour l’instant sur un 404 readthedoc (un 404 en ASCII ART d’ailleurs)

Ensuite à l’utilisation c’est tout simple, un petit exemple, tiré de la doc :

Pour la petite histoire, j’ai découvert cette app en testant django-simple-ratings une autre app du même monsieur.

django-exposure

La encore une petite app toute bête qui permet de resizer des images avant de les afficher. Les images redimensionnées sont stockées en mémoire et il y a même une gestion de cache.

La doc est présente sur packages.python.org et elle explique bien la manière de l’utiliser. Après pour vraiment comprendre, vive les sources.

Quand à l’installation, vous pourrez soit utiliser :

un petit pip install django-exposure
ou une récupération d’un tar.gz sur bitbucket
ou même un hg clone

L’utilisation en elle même est très simple. Il suffit en effet d’utiliser le filtre |resize en lui donnant trois paramêtre, Width, Height et Crop.

Crop peut prendre 5 valeurs de 0 à 5 suivant le crop que vous voulez mettre en place ( 0 étant pour un crop centré).

Pour rester dans le même sujet, je ne peux finir ce billet sans parler de django-thumbnail-works qui sert comme son nom l’indique à gérer les thumbnail. Le principe étant de là, gérer cela directement au niveau de l’ImageField. Mais je ne peux vous en dire plus, je n’ai pas eu le temps de la tester.

Mais comment faire pour masquer d’autre champs ? Comme des champs de KEY d’API ou de password divers ? Parce qu’après tout, il peut arriver de devoir en stocker, et de vouloir les cacher à certains des yeux qui pourraient voir la vue de DEBUG.

He ben, encore une fois, django a tout prévu. Il suffit en effet que le nom de votre constante contienne soit :

• SECRET
• PASSWORD
• PROFANITIES_LIST
• SIGNATURE

Pour que dans les vues de DEBUG, leur valeur soit remplacé par des ***

Et bien entendu, cela marche aussi pour les key des dictionnaires que vous pourriez déclarer dans vos settings (l’exemple parfait étant celui qui sert de configuration pour les BD).