Nov 152011
 

Je vous préviens, tout de suite, j’aurais pu céder à la facilité et parsemer mon billet d’annonce d’image de petit poney rose, pour coller aux thèmes du poney, de django, de l’amour platonique qui anime tout ceux qui font du django ( #sharethelove nan ?? ha non pardon c’est pas la bonne conférence). Mais non, je ne vais pas me laisser aller à cela. C’est dit.

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


flattr this!

 Posted by at 23:54
Nov 012011
 

Deuxième édition de la django app du mois précédent, encore une fois sur le fil, alors que les citrouilles continuent à ricaner dans leurs coins. Ce mois-ci c’est django-ratelimit-backend, une des multiples apps de monsieur Brutasse (qui ne doit jamais dormir pour publier autant de truc…)

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


flattr this!

Sep 302011
 

Cela fait maintenant plusieurs mois que je n’arrive pas à rattraper le retard d’une django app du mois. J’ai donc décidé de suivre les conseils de ce cher daks et d’officialiser mon retard en parlant de Django app du mois précédent. Voici donc la première django app du mois précédent (et bon j’ai bien failli devoir parler de la django app d’il y a deux mois), Django Zinnia, un moteur de blog qu’il est bien (et merci à arcagenis pour la découverte)

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 :

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.


flattr this!

 Posted by at 23:59
Aug 202011
 

Bon, je suis encore en retard pour la django app du mois de juillet, mais je m’améliore, je n’ai plus que 20 jours de retard.

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 :

from autocomplete.views import AutocompleteSettings
class AuthorAutocomplete(AutocompleteSettings):
search_fields = ('^first_name','^last_name')

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 :

from autocomplete.views import autocomplete
autocomplete.register(Reviews.book_author, AuthorAutocomplete)

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 :

class ReviewForm(forms.ModelForm):
author = forms.ChoiceField(widget=AutocompleteWidget(Review.book_author ))

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


flattr this!

Impostor, aucun rapport avec le courrier, la poste ou les gens de petite taille

Avec énormément de retard (non monsieur Daks, je ne vais pas renommer ma rubrique la django app du mois dernier) voici donc la django app du mois de juin. 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- [...]

Django-urlcrypt, après les contes c’est l’url de la crypte.

Voila, comme dit dans le billet précédent, je vais donc faire deux billets de django app de mai, ça m’apprendra à être en retard. 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 [...]

Django-countries ,l’app garantie sans cowboy ni rodéo. djangoApp de mai 1 sur 2

Il va falloir que je me surveille .. parce qu’encore une fois je publie ma django app du mois un peu en retard. Pas grand chose, juste 4 jours.. Mais ça commence comme ça et après on finit par ne plus tenir de rythme du tout. Du coup, pour marquer, le coup, je publierais deux [...]

Admin django, deux petits tips pour les change_list

L’admin django est vraiment un bonheur pour la productivité. On peut faire plein de choses en moins de temps qu’il n’en faut pour écrire le descriptif des choses en questions. 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 [...]

Django-extended-choices, l’app qui te donne le choix (mais pas la date)

J’avais plein d’app possible à présenter pour ce billet du mois d’avril. Mais en réfléchissant, je me suis dit que la meilleure app possible à présenter ce moi-si c’était celle qui a été libéré pendant les DjangoCongs à savoir Django-extended-choices. Et en plus, ce qui est bien, c’est que comme c’est une toute petite app, [...]

Petites apps … petites mais costaudes

Pour ce mois de mars, je vais parler non pas d’une seule mais de deux petites apps. Deux apps parce que les apps sont tellement petites que l’on va m’accuser de tirer au flanc si je ne parle que de l’une d’entre elles. Mais que d’un autre cotés, ce n’est pas parce qu’elles sont petites [...]

DjangoAstuce : masquer certains champs des settings dans la vue de Debug

Par défaut, la vue de DEBUG affiche toutes les settings. Heureusement pour nous, gentils petits djangonautes, les password des BD mais aussi le password du user emails sont remplacés par des belles petites ***.   Mais comment faire pour masquer d’autre champs ? Comme des champs de KEY d’API ou de password divers ? Parce [...]