Le Mad Blog

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

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