Petites découvertes ou redécouvertes des derniers jours.

Le CSRF , mais pourquoi faire ?

Imaginons, juste comme ça hypothétiquement, que vous vouliez désactiver de manière globale la protection CSRF sur la totalité des urls d’un site django.

Vous pensez qu’il suffit de désactiver le middleware qui va bien (soit django.middleware.csrf.CsrfViewMiddleware ) pour que op c’est bon, la vérification CSRF n’est plus mise en place ?

Vous serez alors décontenancé de voir que non, cela ne suffit pas. Il faut aussi ajouter le décorateur csrf_exempt ( qui se trouve dans django.views.decorators.csrf ) sur chacune de vos urls. Un peu compliqué en vrai, surtout si vous avez beaucoup d’urls. _

Comment faire ?

Tout simplement coder un middleware qui va l’enlever pour vous. Vous n’aurez ensuite qu’à le déclarer dans les middleware actifs.


class NOCSRFMiddleware(object):
def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        setattr(request, '_dont_enforce_csrf_checks', True)
        response = self.get_response(request)
        return response

Et voila ! Il suffit ensuite de le déclarer dans MIDDLEWARE et le tour est joué ( par exemple avec un  BadIdeaApp.BadMiddleware.NOCSRFMiddleware

Groupons, Groupons, Groupons !!!

J’avais totalement oublié l’existence du templatetags regroup qui permet de regrouper des objets identique par un attribut commun. Comme regrouper une liste de dictionnaires par les valeurs de l’un des attributs. La documentation complète est disponible ici : https://docs.djangoproject.com/en/4.2/ref/templates/builtins/#regroup

Et redécouvrir ce templatetags m’a été bien utile. Surtout en le couplant avec un autre templatetags que j’avais également oublié, dicsort ( https://docs.djangoproject.com/fr/4.2/ref/templates/builtins/#std-templatefilter-dictsort) qui va trier une liste de dictionnaire par une des clés des dictionnaires.

Comment remplacer une chaine par une autre dans le champ d’un Model Django

Je me suis retrouvé il y a quelques temps avec une problématique, remplacer une chaine par une autre dans un attribut CharField d’un model django.

La première possibilité était de faire tout simplement une belle boucle sur la totalité de mes instances de module, faire le remplacement en python et sauvegarder la nouvelle valeur.


Sauf que j’avais quasiment un million d’objet et que je n’avais pas envie que cela prenne des plombes. Et puis c’était un peu moche.

Du coup j’ai un peu fouillé et miracle, j’ai trouvé une solution que voici.

On commence par définir la fonction de remplacement, tout en django et en SQL.


from django.db.models import F, Func, Value
def replace_func(field_name, old_str, replace_str):
    return Func(
        F(field_name),
        Value(old_str), Value(replace_str),
        function='replace'
    )

Ensuite, il n’y a quasiment plus rien à faire. On va simplement appeler update sur tout les objets et utiliser replace_func.

Par exemple :


MonModele.objects.filter(CONDITIONS).update(
    champ_a_modifier=replace_func("champ_a_modifier",
                                  "str_que_lon_veut_remplacer",
                                  "nouvelle_chaine_de_caractere")

Et voila, c’est fini.

Configurer les représentations textuelles qui seront utilisées dans les ChoiceField des forms Django.

Longtemps que je n’avais pas posté de billets dans cette partie du blog. (Vous allez me dire longtemps que je n’ai pas posté de billet tout court, et vous auriez raison, mais ma bonne résolution de fin de vacances d’été est de changer cela).

Mais donc, pour reprendre doucement dans la partie technique, je vais commencer par partager un truc que tout le monde connaît sûrement déjà. Sauf que perso, j’oublie à chaque fois que cette fonctionnalité de django existe et donc je galère pour la retrouver. Du coup je me dis qu’en l’écrivant je finirais par la mémoriser (et donc en fait j’écris plus pour moi qu’autre chose, je suis un vilain !:) ).

Donc imaginons que vous avez un modèle. Truc assez classique. Ce modèle vous lui avez défini une représentation textuelle de base avec str . Sauf que vous avez plusieurs forms, donc certains ont des ChoiceFields utilisant ce modèle (Exemple un modèle User et vous avez un modèle Post où vous devez choisir le rédacteur du billet). Et manque de chance, vous avez besoin d’une représentation textuelle différentes de celle de base pour un de vos forms. Où même pire, vous avez besoin de plusieurs représentations textuelles différentes, pour plein de forms différents.

Vous êtes alors bien marri.

Mais en fait non, parce que Django vous fourni une façon à la fois simple et élégante de faire. A chaque fois que vous aurez besoin d’une représentation textuelle qui ne soit pas celle par défaut, il vous suffira de définir une classe dérivant de ModelChoiceField et qui implémentera la méthode label_from_instance. Cette méthode prend comme unique paramètre l’objet qui doit voir sa représentation textuelle définit et renvoie une chaîne de caractère.

Petit exemple tiré de la doc django :

from django.forms import ModelChoiceField

class MyModelChoiceField(ModelChoiceField):
    def label_from_instance(self, obj):
        return "My Object #%i" % obj.id

Voilà. Aussi simple que cela. Vous n’avez plus qu’à utiliser votre classe fille de ModelChoiceField dans votre formulaire et le tour et joué.

Bonus, ça marche aussi pour les MultipleChoiceField, il faudra simplement définir une classe fille de ModelMultipleChoiceField

et le lien vers la doc qui parle de tout cela : (https://docs.djangoproject.com/fr/2.0/ref/forms/fields/)

Django 1.7 et écriture de tests, petites explorations

Je me suis enfin lancé dans l’écriture d’une app django gérant les badges (ou les succès si vous préférez). L’objectif étant de pouvoir réécrire de zéro histoires de rôlistes. L’idée était de tenter de faire une vraie app django, en mode réutilisable, histoire que peut-être des gens puissent trouver intéressant de l’utiliser.

Je me suis retrouvé avec deux problèmes concernant mes tests :

  • Souvent on gagne un badge quand on a créé suffisamment de chose (comme des checkin, des billets de blogs ou des contributions diverses). Sauf que je ne voulais pas créer dans mon app des models ne servant à rien, juste pour pouvoir en créer lors de mes tests.
  • Je voulais pouvoir créer des badges se gagnant sur un critère du style ‘être venu un certain nombre de fois sur une URL.’ Donc mettre en place des décorateurs sur des vues. Mais là encore, je ne voulais pas avoir à créer des vues dans mon application rien que pour les tests.

Au final, en lisant un peu de doc, j’ai réussi à faire ce que je voulais.

Tester un décorateur sans créer des  vues inutiles dans son app.

Je savais déjà comment forger des requests avec la RequestFactory. Par contre pour créer des vues, je n’en avais pas la moindre idée.. Une petite question plus tard, Foxmask m’a indiqué un lien qui allait me donner la solution que je cherchais. (le voici) Il suffisait au final d’utiliser mock pour créer, directement dans mes tests, une fausse vue que j’allais pouvoir décorer.
Une dernière subtilité, comme vous le verrez dans le lien novapost (ou dans mon code), si vous utilisez wraps pour créer votre décorateur, il faudra ajouter l’argument assigned=available_attrs(view_func) à votre appel à wraps (tout comme django le fait). Cela sera nécessaire pour pouvoir utiliser votre décorateur en mode fonction, ce que vous devrez faire dans vos tests, à cause d’un bug python 2 (celui-ci :http://bugs.python.org/issue3445)

Créer des models uniquement pour les tests

Ici après quelques test infructueux, je suis finalement tombé sur ce ticket dans le track django. Dont le dernier commentaire remonté à 2 mois. Et en fait, l’astuce est toute simple. Il suffit de créer le model de test dans le fichier de test qui va bien (c’est ici au niveau de mon code) et ensuite de modifier manuellement une des migrations django pour ajouter la création du modèle, uniquement si on est dans le mode Test. Petite modification de mon cru comparé au code donné dans le ticket, j’ai fait en sorte que les models de tests soit créé si la base commence par test ou si elle est stockée en mémoire (mon code est ici).

Rien de bien merveilleux ou de bien révolutionnaire, mais bon, on ne sait jamais, ça pourrait peut-être être utile à l’un d’entre vous.

DjangoIsland, parce que les poneys savent nager

Vous êtes djangonautes ? Et vous n’avez pas encore acheté votre billet pour DjangoCon Europe ?

Alors peut-être que vous ne le saviez pas. Après tout, même si on a essayé de faire un maximum de com sur le sujet, on n’en fait jamais assez et il est fort possible que vous soyez passé à coté.

Donc, je vous refais un petit topo.

3 jours de confs du 13 au 15 mai et 2 jours de sprint le 16 et 17 mai. Et tout cela en France, donc facile au niveau transport, il vous suffit de prendre un TGV.

Mais surtout, surtout, ce ne sont pas trois jours de confs dans une simple salle de conf, aussi belle soit-elle.

Non, ce sont trois jours de confs (et 2 jours de sprint) dans une île. Oui, dans une ILE. L’île des embiez pour être exact, une petite île qui se trouve dans le Var qui appartient à la famille Ricard.

Imaginez donc la scéne. Vous sortez de votre TGV à Toulon, vous prenez un bus et vous arrivez sur un port, le port du Busc. Et la vous prenez un petit ferry et vous voguez, le doux soleil de méditerranée vous réchauffant les neurones.

Et puis après 10 minutes d’une aventureuse traversée, vous accosterez, tel Jim Hawkins, sur l’île des poneys ! Et vous n’en repartirez plus avant 3 (ou 5) jours. Parce que oui, quitte à faire des choses folles, on s’est dit qu’on allait aussi prendre en charge l’hébergement. Comme ça vous n’aurez pas à vous embêter à chercher un hotel proche des conférences, à pester parce que celui que vous vouliez n’a plus de chambre, etc etc, non tout est compris dans le billet.

Et puis on s’est dit que comme c’était sur une île, y il y avait donc des plages. Et que qui dit plage dit baignade. Et que votre conjoint(e) allait peut être vous en vouloir si vous partiez 3 ou 5 jours au soleil sans lui/elle. Donc il y a un forfait pour les accompagnant(e)s et les enfants aussi. Comme ça, vous pouvez même venir en famille.

En fait, la seule chose que l’on ne fournit pas, c’est la crème solaire. Pour le reste, que ça soit nourriture, vin, fromage, ou café, pas de problème. (Par contre, je suis désolé mais je crois que la pizza froide n’est pas au menu des repas… mais vous survivrez à 3 jours sans pizza froide hein ? Surtout si on le remplace par des poissons grillés à la plancha).

Bon après vous allez me dire que tout ça, c’est bien beau. Mais que des confs on y vient surtout pour les confs et pas que pour passer des vacances ; Et qu’il va falloir que le programme il secoue les cocotiers (par contre désolé, il y en a pas sur l’île des cocotiers) un peu, parce que sinon, autant aller à une conf php hein ..

Alors je vous dirais, que vu le programme que l’on vous a préparé, les cocotiers ils vont carrément se trémousser des racines jusqu’au noix de coco. Parce qu’il n’y a vraiment que du bon (et là ce n’est pas l’organisateur qui parle mais le djangonaute impatient).

Vous voulez comprendre à quoi sert App Loading ? (une des nouveautés de la future version). Ca tombe vraiment bien parce qu’Aymeric Augustin vous en parlera pendant une keynote qui s’annonce captivante. Vous faites de l’ecommerce et vous utilisez django-oscar ou vous voulez l’utiliser ? Vous êtes vraiment chanceux, le créateur de django-oscar sera là. Il vous le présentera et bien entendu vous aurez trois jours pour discuter avec lui. Et en plus, comme personne ne quitte l’île, vous êtes sur de ne pas le rater. Il sera forcément là, sur l’île, avec vous ! Et là, je ne vous parle que de deux conférences, mais je pourrais aussi vous parler de Meghan qui va nous parler de expérience utilisateur, de Christophe pettus, de Jacob Burch et Kaplan Moss qui vont disséquer Django, de Julia qui parlera RAD et Django, d’Angel qui mixe Jeux vidéos et REST, etc etc .. Mais je ne vais pas non plus vous faire un copier coller de la page programme, je vous ai donné le lien, vous pourrez juger par vous même et voir quelles seront les confs qui vont vous faire dire ‘Whouaaaa, il faut que j’y sois’.

Donc récapitulons ensemble  :
– un super lieu juste totalement fou (vous voulez des photos, allez en voir ici !! )
– un super programme
– des confs qui sont à la fois des confs et des vacances ( je vous ai dit qu’il y avait une piscine aussi ? Et un sauna ? En accès libre pour les conférenciers ? Non parce que je suis pas sur de vous l’avoir dit)

Maintenant la question que je me pose c’est : Si vous n’avez pas encore votre billet, pourquoi vous perdez du temps à me lire ? Foncez, les ventes seront stoppées le 20 avril au soir !!!

Ha, je pourrais dire aussi que ça sera l’occasion de voir une tripotée de Djangonautes, français ou pas ; l’occasion donc de refaire le monde du développement web une fois de plus, le soir, un verre de ricard (avec ou sans alcool) à la main tandis que le chant des cigales nous bercera doucement.

Non mais vous êtes encore là ? J’espère que vous avez votre ticket alors !!!

Les poneys envahissent la ville rose, aka DjangoCon Toulouse, vive les pains aux chocolats !

Ce week-end avait lieu la première DjangoCon Toulouse, une rencontre django régionale au pays du cassoulet. Les festivités commençaient à 11h30 le samedi avec des LT, puis une rafale de huit conférences l’après midi, et pour finir sprint et ateliers le dimanche.

Cette Djangocon est également la première Cong qui n’était pas un événement autonome mais un événement à l’intérieur d’un autre événement (à savoir le capitole du libre). Je dois avouer que je suis assez partagé sur cette solution de l’événement dans l’événement. Effectivement cela permet d’attirer ‘des curieux’ qui viennent papillonner le temps d’une conférence ou d’un atelier (le nombre de 64 personnes dans l’auditoire a d’ailleurs été atteint). Cela permet aussi d’assister à une conférence de Jérémie Zimmermann la fin du premier jour. Enfin, cela permet de diminuer la charge de travail pour les orgas. Mais cela aussi signifie ne pas être mettre de tout les choix (essentiellement logistique) et de devoir gérer les interactions avec l’organisation globale. Je suis donc partagé sur ce mode d’événement à l’intérieur d’un autre.

Mais venons en maintenant au Djangocon en elles mêmes. Tout d’abord le programme. LT et conférences étaient très intéressants. La rafale de huit conférence l’après midi, conférence de 20 minutes plus 5 minutes de questions auraient pu être difficile à encaisser mais les conférences étant intéressantes et les orateurs d’un bon niveau, tout est passé comme une lettre à la poste.

Étonnamment, les ateliers et sprint du dimanche matin furent même plus productif que ce à quoi je m’attendais. Et l’organisation ‘au dépoté’ (en tout cas ce n’étais pas indiqué dans le programme) d’un atelier d’initiation était une excellente idée. Cela confirme à nouveau mon sentiment qu’il y a une forte demande concernant des initiations à Django et que c’est des choses que les ‘anciens’ de la communauté, les sachants, doivent mettre en place pour partager leur connaissance et jouer le rôle de ‘mentor’.

Alors effectivement, il y a, à mon sens des choses améliorables au niveau logistique, comme l’approvisionnement en jus de fruit / café / eau ou le repas/soirée du samedi soir, mais ce n’est pas si grave que cela (et on revient à mon premier point, le fait de s’intégrer dans un événement plus grand).

Les points positifs importants que je retiens de cette conférence sont :

  • avoir des conférences non totalement centré sur Django est une excellente chose. À Rennes il y avait une conf sur cherrypie et circus, à Toulouse une conf (différente de celle de Rennes) sur circus aussi et ça permet d’ouvrir un peu ses œillères.
  • Les ateliers débutants sont des choses à mettre en place. Se pose la question de les mettre en place dans des Djangocongs d’une taille plus importantes.
  • La soirée du samedi soir est un point très important, de mon point de vue. Les soirées jeux de plateau remportent mes suffrages, pour l’instant.
  • Sprint et ateliers le dimanche matin peuvent être efficaces. Peut-être que la solution est d’en décaler leur démarrage en prenant en compte le besoin de sommeil.

Ces Djangocon sont à mon sens un beau succès et j’ai vraiment été très heureux d’y être. Je profite de ce billet pour, à nouveau, remercier les organisateurs et les orateurs. (Et ce fut assez rigolo de se rendre compte qu’il y avait des ponts très intéressant entre les 2 djangocon Rennes et Toulouse, comme par exemple  une présentation de tastypie à Rennes, suivi d’un atelier Tastypie à Toulouse ).

 

Des poneys avec des chapeaux ronds  aka DjangoBreizh, les poneys envahissent la bretagne

Samedi 17 novembre c’était donc la première edition des DjangoBreizh, une rencontre django locale en bretagne organisé par Exirel (bon ok, je ne suis pas tout a fait breton et pourtant j’y étais mais j’étais une exception) Le programme se découpait ainsi :

  • matin conférence
  • début d’après midi LT
  • reste de l’après midi barcamp ou atelier d’initiation

Pour une première conf, et conf régionale qui plus est, je trouve que le public fut au rendez-vous. 27 personnes pour les conférences, c’est en effet une belle réussite. Pour l’occasion, la cantine numérique de Rennes avait prêté ses locaux toutes la journée, ce qui a permis de mettre en place les conférence du matin et l’atelier initiation du matin (les barcamps se passant à quelques dizaines de mettre à la maison des associations)

Ce que je retiens de cette rencontre régionale (hormis le fait qu’à rennes, il pleut tout le temps) c’est :

  • il peut être difficile d’avoir des conférenciers locaux, il suffit alors de les faire venir d’ailleurs (mais il y a eu un certain nombre de conférencier ‘du cru’ et ça fait plaisir)
  • la partie barcamp est une partie toujours très intéressante et qui fonctionne vraiment bien
  • l’atelier d’initiation était une première, jamais encore cela n’avait eu lieu dans une rencontre django. Le public était restreint (6 à 8 personnes) mais j’ai l’impression que c’est un format qui fonctionne et qui réponds à une vrai demande des gens, un vrai plus de cette édition bretonne, et qu’il faut, à mon avis, répliqué, à minima, dans les autres éditions régionales.
  • Lors des djangocong 2012, certains pensaient que les rencontres régionales allaient ‘faire se relâcher la pression sur la conférence nationale’. A priori, si je généralise à partir de l’exemple de cette première conférence régionale, c’est l’inverse qui va se passer. Les gens qui ‘goûtent’ aux rencontres django régionale, dés qu’ils apprennent qu’il y a des ‘grosses rencontres’, veulent absolument y aller.
  • Le soir c’était free style, une bonne partie des gens se sont retrouvés dans un bar à jeux pour siroter une bière en jouant à des jeu de plateau. Et ce fut excellent. Le format bire et jeu de plateau testé pour la première fois en 2011 montre encore une fois qu’il est un excellent format (voir le meilleur) en ce qui concerne les soirées post conférences (ou inter pour des confs de 2 jours).
  • J’avais peur que les rencontres régionales ne soient que des espèces de mini grandes djangocong, avec uniquement des ‘vieux’ djangonautes présents. Ce ne fut pas le cas et c’est tant mieux.

En résumé, ce fut une excellent première édition et j’ai hâte de voir ce que donnera la deuxième édtion (si il y en a une).

En tout cas merci à Exirel d’avoir organiser tout cela, à la cantine numérique de Rennes d’avoir participé à l’aventure des django en bretagne, aux auditeurs d’être venus faire des conférences de qualités et aux rennais d’avoir répondu présent.

Et à la semainse prochaine pour DjangoCassoulet à Toulouse !!!!! Espérons qu’il y aura des pains au chocolat !

Django, websocket et bidouillage.

Lors du Django Meetup Paris numéro 2 (qui a eu lieu dans les locaux de 20 minutes, merci à eux pour le prêt de la salle (et à Julien pour l’orga) ), un petit récap des confs EuroDjango a été fait par Samuel (le frère de David, et oui un Paccoud peut en cacher un autre!!). Apparemment un des sujets porteur des EuroDjango avait été le ‘web temps réel’ (ce que je déteste ce terme tiens … temps réel, ça a un sens.. ça ne veut pas juste dire un truc en mode connecté) et la mise en place de celui ci dans Django (et du fait que peut être notre framework adoré n’était pas super en avance sur ce sujet).

J’en ai profité pour donner mon avis sur la question. A savoir qu’à mon sens, les serveurs webs n’était pas fait du tout pour gérer des connexions en mode connecté. Parce qu’ils n’ont pas été prévu pour cela. Idem pour le cœur de django qui n’est pas fait pour garder des pools de sockets, des états par connexion clientes, etc etc …

Alors qu’à contrario il y a des frameworks (je pense à twistted mais pas seulement) ou des manières d’écrire des serveurs qui permettent de gérer proprement des communications en mode connectées.

Il me semblait donc logique de ‘sortir’ la partie websocket du cœur de Django pour qu’elle soit gérer par ‘autre chose’. Il me semble qu’à la fin de ma tirade explicative, quelqu’un m’a dit ‘ben ok, fait le’ (me demande même si ce n’est pas ce fourbe de n1k0)

Du coup, ben ayant eu un peu de temps, ces jours-ci, j’ai rapidement fait un proto merdique de test.

Le principe a été de prendre l’exemple de simple chat de Gevent-SocketIO et de le ‘transformer’ en une commande de management Django. La commande de management simulant un serveur de gestion des connexions socketIO des utilisateurs. Du coté django, on a une première vue qui demande de donner un nickname puis on se retrouve sur la fenêtre de chat (qui utilise socketIO) et on peut discuter avec les autres connectés. J’ai rajouté deux petits trucs, pour le plaisir, le fait d’avoir les 5 dernières lignes de discussion (ça se récupère par la partie WebSocket) et le nombre de user et lignes de discussions totales (s’affiche la première fois par la connexion HTTP classique, se met à jour par les WebSocket)

Il faut donc à un moment ou un autre, lier la partie DjangoWeb de la partie SocketIO. Comme ce n’est qu’un prototype pour m’amuser, je passe à la vue de chat une key généré aléatoirement, key que me renvoie le client JS à travers la websocket.

Bon, bien entendu, tout cela n’est qu’un prototype pour expliquer (avec du code) la manière dont je voyais les choses. Bien entendu bis, il faudrait ‘lier’ la partie Web classique et Websocket d’une meilleure façon, ne pas utiliser une commande de management brute de décoffrage, potentiellement  élaguer pas mal gevent-socketio pour enlever tout ce dont on n’aurait pas besoin, etc etc …

Mais voilà, j’avais juste envie de faire un test, d’en parler ici et de vous demander votre avis sur la question:)

Orateurs, les rencontres django régionales ont besoin de vous !

L’un des résultats des discussions de la dernière DjangoCong fut de lancer l’idée de faire des DjangoCon régionales plus petites et qui permettraient de ne pas centraliser les attentes de toute la communauté sur un seul événement national. Et du coup d’éviter de générer de la frustration pour ceux qui n’ont pu acheter leurs billets et qui enragent, chez eux, parce qu’ils loupent la grand messe django FR. (pour avoir une idée de ce que cela peut donner, voir ce lien (oui je sais c’est un vieux lien, mais il est parfait pour la situation) ).

Deux première initiatives ont été finalement été lancés :

  • DjangoBreizh à Rennes (vive la Bretagne, le temps pourris, le cidre et les crêpes) le samedi 17 novembre.
  • DjangoCon Toulouse (ils ont oublié un g à la fin du nom.. tss tss, mais bon vive le cassoulet) le 24 et 25 novembre.

C’est avec une grande joie que j’ai vu naître ces deux initiatives locales (d’ailleurs je serais présent, d’une manière quasi certaine à Rennes et peut-être, mais vraiment peut-être à Toulouse). Parce que ce n’est pas forcément évident d’organiser des conférences, même ‘juste locale’. Et que même dans certains domaines, il me semble que c’est plus difficile d’organiser une conférence locale que nationale.

Et un point qui peut, peut-être, être problématique, c’est la visibilité moindre de ces conférences, qui fait que mécaniquement, il y a moins d’orateurs potentiels qui en entendent parler et donc moins de propositions.

D’où mon billet du jour. Parce que pour réussir une bonne conférence, il faut une équipe organisatrice, un public et des orateurs. Et d’une vision tout à fait extérieure, j’ai vu peu de gens twitter ‘j’ai proposé ma conf pour DjangoToulouse ou DjangoBreizh’. C’est sûrement du au fait que conférences régionales dit moins de visibilité … (mais je l’ai déjà dit ça). Mais ça n’en reste pas moins ennuyeux.

Donc pour essayer de donner un peu plus de visibilité, je me fends de ce modeste billet. Comme ça vous ne pourrez plus dire que vous n’étiez pas au courant. Parce que maintenant vous l’êtes.

Alors proposez vos conf !

Pour les fainéants, je mets les liens direct vers les appels à conférences :

 

Installation de virtualenvwrapper chez Alwaysdata

J’ai il y a quelques temps fait de multiples tests chez AD. Certains nécessitaient l’utilisation de paquet python non installé par défaut sur le serveur mutu AD. Du coup, j’ai voulu installer virtualenwrapper pour me simplifier la tache.

Voici la méthode que j’ai utilisé. Je suis preneur de toute amélioration que vous pourriez me remonter sur ma manière de faire (pour le jour où j’aurais vraiment besoin d’installer des choses pour faire de la prod avec du virtualenv). D’ailleurs je la partage ici autant pour le plaisir de la partager, que pour ne pas l’oublier que pour vous permettre de l’améliorer.

Le commencement, installer virtualenwrapper. En local sur son home. En faisant :

pip install --install-option="--user" virtualenvwrapper

du coup cela vous installe le tout dans $HOME/.local/….

Une fois installé, il faut faire (comme pour installation normale) la création du répertoire de vos environnements en faisant :

export WORKON_HOME=$HOME/.virtualenvs
mkdir -p $WORKON_HOME

Ensuite histoire de ne plus avoir à le faire, dans votre .bash_profile :

export PYTHONPATH=~/.local 
export WORKON_HOME=~/.virtualenvs 
export PATH=$PATH:$PYTHONPATH/bin 
source ~/.local/bin/virtualenvwrapper.sh

un petit coup de

source ~/.local/bin/virtualenvwrapper.sh

et Voila ! (à dire comme avec l’accent d’un américain qui prend un accent français).

Vous aller pouvoir faire des mkvirtualenv en veux tu en voilà !

(Un petit tips, si vous faites du django, il ne faut pas oublier dans votre django.fcgi d’ajouter une ligne

 sys.path.insert(0,'/home/$USER/.virtualenvs /VENV_NAME/lib/python2.6/site-packages'

)

Pony rider in the skyyyy… c’est le retour des djangocong YeeHa !!

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

Django-ratelimit-backend ne réglera pas vos problèmes de foie, mais de rate oui…

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