Mathieu Agopian

Djangocong 2012 !

2011-11-14T10:49:00Z

C'est à nouveau ce moment de l'année ou la nouvelle tant attendue est enfin annoncée : la conférence française sur Django aura lieu pour la troisième année consécutive, cette fois-ci sur Montpellier.

Cette année, donc, plusieurs nouveautés :

la conférence aura lieu sur Montpellier, les deux précédentes ayant été sur Marseille
il est possible de coucher sur place (ou juste à côté)
le lieu des conférences est sur la plage
tous les lieux (conférences, couchage, apéro communautaire du samedi soir) sont très proches et accessibles à pied

Niveau programme, le même principe qui a fait le succès de la dernière édition est repris :

samedi matin : "on a fait", retours d'expérience sous la forme de conférences courtes (12 minutes) ou de lightning talks (5 minutes)
samedi après-midi : "on discute", ateliers participatifs, aussi connus sous le nom de barcamp
samedi soir : apéro communautaire, occasion idéale pour boire et manger ensemble, faire connaissance, échanger à bâtons rompus ...
dimanche matin : "on fait", sous la forme de sprints
dimanche après-midi : "on refait le monde", soit sur la plage, en balade, autour d'un bœuf musical ... détente !

Mais le programme, lui, dépends en grande partie de TOI ! Il dépendra des sujets que tu aura proposés, tu es donc responsable en grande partie de sa teneur !

Pour pouvoir organiser la meilleure rencontre possible, nous avons donc besoin de ton aide, et ce de différentes manières. Voici ce que tu peut faire pour notre rencontre :

proposer un sujet de conférence : tu as créé ou utilisé une librairie qui mérite d'être connue, tu as mis en place des méthodes ou outils pour faciliter ton développement web avec Django, ou tout simplement une expérience à partager ? C'est le format qu'il te faut !
proposer un lightning talk : idéal pour des sujets courts, pêchus, dynamiques, rigolos, pour présenter la dernière nouveauté, pour faire connaître son projet, sa communauté, une idée... beaucoup plus libre et dynamique qu'une conférence* *
parler de cette rencontre (et de son appel à conférence) autour de toi, en faisant connaître le lien vers Djangocong 2012
demander à des personnes que tu connaît de proposer une conférence ou un lightning talk sur un sujet qu'il maîtrise et que tu aimerait voir présenté

Tu as jusqu'au 13 janvier 2012 inclus, donc ne perd pas de temps !

Pour ma part j'ai déjà proposé trois sujets, et toi ?

P.S: tu comptes venir à la conférence, et tu aimerais amener femme et enfants ? Il semblerait que tu ne soit pas le seul, il y aura donc probablement d'autres "accompagnants" avec qui passer du bon temps ! Plus d'informations sur le sujet à venir, et je vous tiendrais bien entendu informés de l'ouverture des inscriptions !

Point-virgule

2011-10-13T08:30:00Z

(Ceci est mon premier essai d'écriture. Je trouve l'idée sympa, mais la réalisation est au mieux moyenne... faites moi connaître votre avis et conseils d'amélioration dans les commentaires !)

Ça a recommencé.

Tout va être à refaire, tout ce que nous avons construit, patiemment, péniblement, durant les 80 dernières années. Voilà l'amer constat qu'il m'est donné de faire, au crépuscule de ma vie.

J'avais espéré pouvoir offrir à mes pairs, mes confrères et amis, un avenir plus radieux que celui qui nous était initialement réservé.

Tout s'était mis en place, pièce après pièce, comme un puzzle, comme un Tetris bien engagé.

Le point de départ : une morne journée d'octobre, et un développeur de plus qui se fait dire que son boulot devrait être réservé aux débutants, aux jeunes diplômés. Les mots résonnent encore dans ma tête : "Le développement, c'est bouché, ça n'a pas d'avenir dans la vie d'un homme. Il faut savoir évoluer, devenir chef de projet, consultant, technico-commercial. Tout sauf rester prostré devant son ordinateur, en concurrence avec les milliers d'autres programmeurs frais sortis de l'école, toute cette main d'oeuvre bon marché. Il faut que tu saches qu'aujourd'hui, trouver un programmeur c'est super facile. Un conseil, évolue." Ces mots lâchés par un patron vraiment plus au goût du jour, dépassé, mais toujours aussi puissant, ont fait écho aux nombreuses plaintes, rancoeurs et billets de blogs traitant du sujet : le développement n'était pas apprécié à sa juste valeur, n'était pas apprécié du tout en fait. Et cette mentalité rampante était devenue à la mode, comme une évidence.

Pourtant, le manque de développeurs était flagrant. Trouver un collaborateur ou employé expérimenté, motivé et qui se tenait informé des dernières avancées techniques était de plus en plus compliqué. Les plus grandes entreprises comme Mozilla et Google attiraient la plupart de ces perles rares qui savaient pouvoir y trouver un hâvre de paix, de sérénité, et de liberté dans leur travail quotidien. Un endroit leur permettant d'exprimer leur créativité, et leur plein potentiel.

La bascule a d'abord été imperceptible. Sous l'action d'un petit groupe de Djangonautes (terme maintenant oublié depuis longtemps), les évènements se sont enchainés :

tout d'abord les prix journaliers des indépendants ont augmenté, d'abord lentement, puis de plus en plus rapidement pour atteindre les prétentions de rockstars du SEO.
la mort d'une idôle de plusieurs générations, le grand Steve, et son image de "technologie utilisable par tous". Lui et son idée du "design avant tout" avaient fait de l'ombre pendant trop longtemps au travail des milliers de développeurs qui avaient été nécessaires à ses gadgets.
la création de nouveaux langages de programmation, comme Dart, qui reniaient les avancées en lisibilité et clarté acquises laborieusement par certains pionniers, dont Py^W ... celui que l'on ne saurait nommer.
la généralisation de l'utilisation de langages complexes, d'abord Java, puis Ruby, Dart, Pronog, Cortran, kobol, et enfin, le langage qui les remplaça tous, le seul et unique autorisé de nos jours, l'Ensembleur.
les initiatives incessantes de minimisation de l'intérêt de la documentation, que ce soit sur les API, les langages, ou les projets, leur ROI étant inexistant.

Une fois tout ça en place, l'étape suivant fût d'imposer des restrictions sur les places disponibles en école informatique. Pour faire voter une telle loi, il suffisait de se mettre quelques politiciens dans la poche. En effet, depuis de très nombreuses années déjà ils étaient devenus maître dans l'art de l'absurde, dans l'art de présenter une idée comme étant la solution logique à un problème, alors que c'était exactement le contraire qui était recherché.

Quelques exemples:

On ne veut pas que le piratage de la musique soit facile ? On va limiter les téléchargements gratuits (et donc renforcer et enrichir les solutions de piratage payantes).

Il y a des problèmes de sécurité depuis qu'on a augmenté les sanctions, et diminué la prévention ? Continuons dans cette voie, et augmentons encore les sanctions, et diminuons d'autant la prévention.

Ces raisonnements illogiques, présentés comme les seuls valables, ont pavé le chemin à la grande loi : il y avait un manque d'informaticiens, de développeurs ? Limitons les places dans les écoles d'informatique pour les réserver à une "élite", qui serait bien plus efficace. Grâce au lobby alors puissant des Congs, cette loi fût votée dans le plus grand secret, en pleine nuit, par une poignée de fidèles, et ne rencontra donc aucune opposition.

Le plan se déroulait à merveille jusque là, et il alors fallut franchir le cap le plus difficile : le bannissement pur et simple du langage qu'on ne saurait nommer, et du framework plébiscité jusque là par les adeptes du web, le framework au poney magique.

Sans cette dernière étape, il n'aurait jamais été possible d'arriver où nous en sommes maintenant. Ou devrais-je dire, où nous en étions il y a encore quelques années.

Il n'était pas envisageable de garder un langage aussi facile, accessible à tous et efficace, sous peine de fragiliser la main-mise des informaticiens sur le précieux code.

Nous, les développeurs, sommes maintenant une caste renommée et appréciée de tous, ou plutôt crainte de tous. N'étant plus qu'une centaine de par le monde, nous imposons notre volonté aux hommes d'états comme aux chefs d'entreprise. Quand nous nous déplaçons, les foules nous acclament en espérant que nous daignerons continuer à maintenir les infrastructures, les services et programmes qui régulent la vie quotidien des 12 milliards d'habitants de notre planète.

Oui, dernièrement, la vieillesse aidant, nous nous sommes ramollis. Notre emprise de fer s'est assouplie, et certains pseudo-langages ont fait une timide apparition. Bien entendu, les créateurs étaient immédiatement arrêtés, convertis, puis assujettis à notre cause.

Oui, ces pseudo-langages persistaient parfois pendant quelques mois, soutenus et améliorés par quelques dissidents, quelques résistants du monde de l'opensource, ces illuminés qui ne comprenaient pas notre vision. En général une descente de flics chez ces derniers suffisait à calmer leurs ardeurs.

Oui, depuis quelques années, notre influence diminuait, et les foules qui s'ammassaient sur nos trajets avaient l'air moins craintives, plus hargneuses et revendicatrices.

Oui, j'ai entendu parler il y a quelques mois d'un langage qui persistait, et son nom aurait dû me mettre la puce à l'oreille : Boa.

Boa.

Voilà un nom étrangement évocateur. Il paraît que son auteur est Hollandais, et qui plus est, barbu. On m'a même dit que ce langage n'utilisait ni accolade, ni même de point-virgule ! Sacrilège !

Nous aurions dû nous en inquiéter, nous aurions dû préparer la relève il y a bien longtemps, une relève forte qui nous aurait sorti de ce mauvais pas.

Ça a recommencé... mon infirmière, au détour d'une conversation, m'a dit hier ces quelques mots, d'apparence anodine, mais qui résonnent depuis dans ma tête. Ces quelques mots annonciateurs du retour du grand mal :

"j'ai une super idée, et je vais demander à mon neveu de me la programmer".

La bidouille django du jour: appeller un templatetag depuis un autre templatetag

2011-05-11T11:59:00Z

Cet article n'est pas écrit par Mathieu. Enfin si, mais par un autre Mathieu, qui n'a pas de blog en ce moment et abuse^Wprofite de la gentillesse du maître de ces lieux pour poster ici.

Introduction

Avez vous toujours rêvé d'appeler un templatetag Django depuis un autre templatetag ? Allez, avouez-le : dans vos rêves les plus fous, vous aimeriez pouvoir faire:

@register.simple_tag
def my_templatetag():
    if condition:
        return tag1()
    else:
        return tag2()

Ça marchera si vos tag1 et tag2 sont des simple_tags, vu que c'est directement une chaîne de caractères qui est retournée. Là où ça commence à se compliquer, c'est si vous voulez que ça marche avec n'importe quel templatetag, et notamment les inclusion_tags. En effet, en appelant un inclusion_tag "à la main", vous vous retrouvez avec juste le dictionnaire qu'il retourne comme contexte, au lieu d'avoir le "vrai" résultat.

Zut, mais comment faire alors ?

Pour comprendre comment faire pour contourner ce problème, il faut regarder comment un templatetag fonctionne. Quand vous déclarez un inclusion_tag ou un tag classique, que se passe-t-il ?

Tout d'abord, via le décorateur @register.tag ou @register.inclusion_tag, votre templatetag est enregistré dans la variable register, que vous avez dû déclarer de la sorte: register = Library().
Si on inspecte cette fameuse Library, on se rend compte que chaque tag s'enregistre dans un dictionnaire, dans l'attribut tags. Ce dictionnaire contient la fonction permettant de générer l'instance de Node correspondant à votre tag. Dans le cas d'un inclusion_tag, il y a un peu de complexité qui vous est planquée, vu que, contrairement à l'enregistrement d'un tag "classique" via @register.tag, vous ne déclarez pas de sous-classe de Node, et vous ne jouez pas non plus avec un parser de tokens.
Au moment où le template rencontre votre templatetag, il récupère la fonction à appeler dans l'instance de Library qui va bien, et instancie le Node avec parser (l'instance du Parser) et token (l'instance de Token correspondant à tout ce qui était entre {% et %})
Ensuite, au moment d'afficher votre template, la méthode render() de chaque Node est appelée. Celle-ci reçoit notamment le contexte courant.

Du coup, la grosse bidouille consiste simplement à faire la même chose que Django fait. Ça donne ça:

@register.tag
def my_templatetag(parser, token):
    # On suppose que vous êtes dans le même module, sinon il faut aller chercher le register
    # qui va bien dans un autre module python
    if condition:
        return register.tags['tag1'](parser, token)
    else:
        return register.tags['tag2'](parser, token)

La beauté du truc, c'est que vous enregistrez un tag normal, mais quand il est appelé, il utilise une autre instance de Node, qui provient d'un de ses copains.

Gestion des paramètres

Il reste cependant un écueil : comment gérer les paramètres ? C'est en fait très facile: il faut modifier le token qu'on passe pour tromper Django. Et c'est là où la bidouille est un peu crade, vous devez faire comme si on appelait le templatetag depuis le template:

@register.tag
def my_templatetag(parser, token):
    # On suppose que vous êtes dans le même module, sinon il faut aller chercher le register
    # qui va bien dans un autre module python
    if condition:
        token.contents = 'tag1 argument1 argument2'
        return register.tags['tag1'](parser, token)
    else:
        token.contents = 'tag2 argument1 argument2 argument3'
        return register.tags['tag2'](parser, token)

Conclusion

Et voilà ! Je vous conseille, si vous utilisez cette technique, même si vous n'avez pas besoin d'arguments, de toujours modifier token.contents, histoire d'être sûr.

On peut encore pousser le vice plus loin et gérer des paramètres dans notre templatetag 'parent', mais ça suffit pour aujourd'hui :)

Contribuer à Django, premiers pas (patcher la doc)

2011-04-30T17:46:00Z

Ceci est le troisième article dans la série, les premiers étant

On sait donc quoi faire d'un ticket, et on a tous les outils en place pour y répondre, c'est parti pour une contribution à la documentation !

Choisir son ticket

Nous avons vu dans le premier article de la série qu'on peut trouver les tickets soit sur la page Reports de trac, soit sur le super dashbord que Jacob Kaplan-Moss vient de créer.

Pour ma part, je me focalise pour le moment sur les tickets qui sont unreviewed (non revus, qui viennent d'être créés).

N'oubliez pas qu'il est tout à fait possible, et même encouragé, de :

ne pas s'occuper de tickets pour lesquels on ne se sent pas à la hauteur
demander de l'aide sur le salon #django-dev sur le serveur irc freenode
lancer des discussions pour avoir plus d'informations ou d'avis sur la liste de diffusion *django-dev*

Nous allons, pour illustrer ce billet, examiner le ticket #15886 dont le titre est "Improve django.core.serializers.get_serializer() docs".

Revendiquer le ticket

Comme indiqué dans la doc sur la contribution, il est conseillé de claim (revendiquer) un ticket avant de travailler dessus, pour éviter de se retrouver à plusieurs sur le même ticket en parallèle, et sans le savoir. Vu le nombre de contributeurs potentiels, il y a un risque que quelqu'un d'autre soit déjà en train de travailler sur un patch.

Revendiquer le ticket se fait très simplement en sélectionnant accept, tout en bas de la page de modification d'un ticket.

Il est par contre inutile de revendiquer un ticket pour les cas les plus simples, ne nécessitant que quelques minutes de travail. Il suffit alors de soumettre le patch directement, et c'est ce que j'ai fait pour l'exemple choisi pour illustrer cet article.

Première étape : faire une revue du ticket

Comme vous pouvez le constater, j'ai revu le ticket, et j'ai posté un commentaire conseillant de créer un autre ticket séparé pour n'avoir qu'un seul problème à résoudre dans celui-ci. Je n'ai pas changé l'état du ticket, n'étant pas certain de ce qu'il fallait en faire.

Il faut noter que toute contribution (même un simple commentaire) peut être utile et précieuse. Dans ce cas précis, il a servi à faire créer un nouveau ticket, et à initier la discussion.

Dans ce cas particulier, Jacob a passé le ticket en accepted, vraisemblablement parce qu'il ne restait pas d'objection : le problème identifié dans le ticket (le manque de documentation) est maintenant clairement séparé de la demande de nouvelle fonctionnalité, et le "composant" concerné a bien été mis à jour.

Deuxième étape : proposer un patch

Et pour ça, rien de bien compliqué. Dans le précédent article, nous avons vu comment mettre en place un projet brouillon, et surtout comme cloner le code source de Django, et compiler sa documentation.

Modifier la documentation

Pour cela, il faut déjà repérer la page concernée dans la documentation de Django. Toujours en nous référant au ticket #15886 de l'exemple, un gentil contributeur a déjà apporté un commentaire, et indiqué le lien vers la page http://docs.djangoproject.com/en/1.3/topics/serialization/ (oui, ça tombe bien, ce gentil contributeur, c'était moi ;)).

Si on inspecte l'url, on peut voir qu'il s'agit de la page "serialization" dans la catégorie "topics". Le fichier correspondant, dans le code source de Django, se trouve donc logiquement dans

$ cd ~/projects/django/docs
$ vi serialization.txt

Dans mon cas, j'utilise le meilleur des éditeur, mais vous avez bien entendu le choix des armes ;)

Une fois le bon endroit localisé pour apporter la clarification demandée dans le ticket, il suffit de rajouter quelques lignes, en utilisant son meilleur anglais.

Il est à ce propos fortement conseillé d'avoir au moins quelques notions de sphinx, l'outil utilisé pour générer la doc, et connaître les ajouts apportés pour Django dans la page sur la contribution à la documentation.

Compiler la documentation

Nous l'avons vu dans le précédent article, il suffit pour celà d'utiliser la commande suivante :

$ make html

Si il y a le moindre problème de syntaxe reStructuredText vous le verrez lors de l'exécution de cette commande. Il suffit alors de consulter le résultat sur file:///chemin/vers/projects/django/docs/_build/html/index.html.

Créer le patch

Si vous avez suivi la méthode proposé dans le précédent article, vous avez le cloné le miroir git de Django, et pouvez donc utilisez la méthode ultra simple suivante :

créer une branche de développement pour y stocker les modifications à apporter : $ git checkout -b dev
apporter les modifications nécessaires
commit les changements régulièrement, et retourner en 2. tant que c'est nécessaire : $ git commit -a -m "un message de commit"
une fois fini, créer le patch : $ git diff master > nom_de_mon_patch.diff

Il est très fortement recommandé de créer un patch avec l'extension .diff pour qu'il soit correctement traité et affiché par trac, et de l'attacher au ticket (au lieu de pointer vers un diff ou un pull request sur github ou autre), pour simplifier au maximum la dure et (déjà) fastidieuse tâche des core developpers.

Et surtout ne pas oublier de rajouter le flag "has patch" !

Pour reprendre notre exemple, vous pouvez visualiser le patch final.

Attendre la validation de la communauté

Dans ce cas précis, j'étais inquiet de la dépendance qu'il pouvait y avoir sur le ticket #15889, qui est le ticket créé en parallèle pour la demande d'ajout de fonctionnalité (renvoyer une exception spécifique au lieu de KeyError). En effet, si le ticket #15889 était intégré dans Django (avec la documentation associée), avant le ticket #15886, il résulterait un problème de cohérence, avec deux parties de la même documentation indiquant une levée d'exception différente.

J'ai donc soulevé la question sur le salon irc #django-dev, et la réaction a été rapide : Alex a eu la gentillesse de répondre à mes craintes en fermant le ticket comme étant un duplicat du ticket #15889.

Bah oui, mais mon patch alors ?

Et là, j'ai envie de répondre : "C'est le jeu, ma pov' Lucette" !

Plus sérieusement, peu importe le temps passé (dans ce cas, vraiment minime) sur un ticket, au final le but est de

rendre Django meilleur
apporter sa modeste contribution si nécessaire
faciliter au maximum la tâche des core devs
apprendre le plus possible au passage quand l'opportunité se présente

Astuce : se rajouter dans les destinataires

Il suffit pour cela de cocher la case add to cc en bas du ticket, et de sauvegarder. Si vous êtes enregistré et connecté, votre adresse mail devrait être automatiquement ajoutée dans la liste des personnes qui seront en copie du mail envoyé lors de chaque modification du ticket : commentaire, changement d'état...

L'intérêt, en plus de recevoir les mails sur les tickets qui nous concernent, est de pouvoir faire un filtre personnalisé pour afficher tous ces tickets.

Avec ce genre de requête personnalisée, il est beaucoup plus facile de suivre l'évolution de "ses" tickets, et de pouvoir utiliser l'offre 5-for-1 !

Sud Web, c'est bon pour ton web

2011-04-27T09:30:00Z

En un mot comme en cent :

Et toi, cher lecteur ? As-tu pensé à réserver ta place ? Dépêche-toi, il ne reste plus que 5 jours !

Mais c'est quoi Sud Web ?

Sud Web est une conférence qui aura lieu le 27 mai 2011 à Nîmes, donc dans le sud, et (normalement) au soleil. Elle se tiendra sur une journée dans les locaux de l'Ecoles des Mines d'Alès (oui, à Nîmes ;)), et rassemblera quelques orateurs et oratrices trié(e)s sur le volet, avec des sujets répondant au slogan "Savoir-faire et faire-savoir".

Méthodologies, standards, de grands noms du Web (Karl Dubost pour ne citer que le plus connu) seront là pour nous présenter des sujets allant de la technique (SVG pour les designers et les développeurs) à la méthode (Anatomie d'une mission agile) en passant par des sujets plus vastes (Le web et l'efficience de l'intervention humanitaire).

Il y en a bien d'autres (y compris plusieurs lightning talks vraiment sympathiques), tous listés pour votre plus grand plaisir sur la page du programme.

Mais il n'y a pas que le programme, bien entendu, qui fait le succès d'une conférence, il y a aussi et surtout les rencontres, et c'est pour ça que nous vous avons concocté une soirée communautaire qui promet d'être riche en échanges, et ce dans un cadre très agréable.

Y'a un lien avec Paris Web ?

Oui et non. Comment ça elle est inutile ma réponse ?

Oui

Sud Web est parti d'une initiative de plusieurs passionnés du Web, qui lors de leur dernière rencontre à Paris Web 2010, ont décidé de se lancer dans l'aventure de créer et organiser une conférence Web, mais cette fois-ci dans le sud.

Non

Les organisateurs (dont j'ai la chance de faire partie) ont vraiment souhaité avoir une conférence (petite sœur de Paris Web), mais sur une thématique résolument différente.

Oui, la conférence va recevoir quelques-uns des orateurs qui ont déjà présenté à Paris Web (sur d'autres sujets), et oui Sud Web est aussi soutenu par le W3C, mais non, ce n'est pas une copie conforme avec (probablement) le soleil en plus et (espérons) les grèves en moins.

Autre chose ?

Oui, plusieurs autres choses d'ailleurs, et en vrac :

une conférence no-wifi comme lors de Djangocong
un débat en fin de journée sur la question Où va le Web animé par Marc Lipskier
des goodies
des repas compris dans le prix
la chance pour moi de revoir David Larlet, Jean-Michel Armand, Nicolas Perriault, Mathieu Pillard et Nicolas Dubois que j'ai vus il y a peu à Djangocong

Conclusion ?

Moi j'y vais, et toi donc ? Vite vite il ne reste plus que quelques jours !

Contribuer à Django, premiers pas (les outils, l'environnement)

2011-04-25T13:52:00Z

Ceci est le deuxième article dans la série, le premier étant Contribuer à Django, premiers pas (revue de tickets).

Maintenant qu'on a compris le flow entre les différents états de tickets, et les flags associés, passons aux choses sérieuses : la soumission d'un patch !

Mais avant de pouvoir soumettre un patch, il faut avoir son environnement prêt, c'est à dire une version récente du trunk, un projet brouillon et une application de test, et enfin les différentes dépendances nécessaires.

La démarche expliquée ici utilise git, qui semble être la méthode la plus répandue (autre que svn, que je connais moins bien).

Créer son virtualenv

Tout le monde sait comment créer un virtualenv de nos jours, n'est-ce pas ? Pour ceux qui ne connaissent pas encore cet excellent outil, je leur conseille vivement de s'y intéresser, ainsi qu'à pip, et à virtualenvwrapper pour les fainéant (et la fainéantise, c'est bien).

$ mkvirtualenv scratch

Créer son projet

Il est recommandé d'avoir un squelette de projet Django, pour pouvoir démarrer plus rapidement, sans avoir à répéter sans cesse les mêmes actions. Celui que j'utilise pour mes projets réels se trouve ici, et je vous conseille d'avoir le votre, avec vos propres réglages !

Dans le cas de la contribution à Django, j'ai créé un autre squelette, django_scratch, qui n'a pas d'autres applications installées que celles par défaut, en rajoutant l'admin et une application de test vide.

$ cd ~/projects/
$ hg clone https://magopian@bitbucket.org/magopian/django_scratch scratch
$ cd scratch

Cloner le repository de django

Il existe un miroir du svn de Django sur github que nous allons utiliser, mais vu que je suis super sympa, je vous l'ai déjà mis dans les requirements de pip :

$ pip install -r pip_requirements.txt

Pour le même prix, sphinx (qui dépends de pygments) sera installé par la même occasion, outil indispensable pour pouvoir contribuer à la documentation.

Finaliser

Vous avez normalement tout ce qu'il faut pour débuter votre carrière de contributeur !

Une base de donnée sqlite

Par défaut, c'est le moteur utilisé, car plus rapide pour les tests et surtout beaucoup plus simple à configurer. Pour faciliter les choses, il y a déjà scratch.db.save qui est une base initialisée avec les tables nécessaires à Django, et même un admin (login: admin, pass: admin).

Pour l'utiliser, ou la ré-utiliser pour revenir à la configuration de base :

$ cp scratch.db.save scratch.db

Il y a aussi mysql_settings.py et postgresql_settings.py qui sont là pour les cas où le moteur de base de données est important et doit être testé. Il vous suffit d'écraser settings.py avec le fichier de votre choix, et de créer un fichier creds.py qui contient (à modifier avec vos user/pass bien entendu) :

# creds.py
MY_CREDS = {'user': 'foo', 'pass': 'bar'}
PG_CREDS = {'user': 'foo', 'pass': 'bar'}

Une application de test

Cette application est constituée d'un modèle Foo avec un seul champ name, l'AdminModel qui va avec, un urls.py et views.py basiques.

Le but est d'avoir le minimum nécessaire à la reproduction de la majorité des bugs, et ce avec un minimum de travail. N'oubliez pas de faire un syncdb pour que le(s) modèle(s) soi(en)t créé(s) !

Le trunk de Django

Il a été cloné directement dans le répertoire src de votre virtualenv. Si vous avez suivi exactement tout ce qui a été indiqué dans ce billet, vous devriez pouvoir créer un lien symbolique du répertoire de Django à un endroit plus pratique et accessible (vous allez devoir y modifier des fichiers régulièrement) :

$ ln -s ~/.virtualenvs/scratch/src/django ~/projects/

De la documentation en sphinx

Elle se trouve directement dans le répertoire docs du trunk de Django, et pour la générer, rien de plus simple :

$ cd ~/projects/django/docs
$ make html

S'ensuit la génération de tous les fichiers html de la documentation de Django, que vous pourrez visualiser et contrôler en pointant votre navigateur sur le répertoire _build/html/ :

file:///chemin/vers/projects/django/docs/_build/html/index.html

Bon, et donc, quand est-ce qu'on contribue ? Nous verrons ça dans le prochain article, promis !

Contribuer à Django, premiers pas (revue de tickets)

2011-04-24T17:41:00Z

Contribuer au framework web Django... tout un programme, et très effrayant de prime abord. Depuis des années que j'utilise le framework, je commence tout juste à y contribuer, et je peux vous assurer que jusqu'à hier encore, je ne pensais pas être à la hauteur.

Or, ce qu'il y a de génial, c'est que tout le monde est à la hauteur, et que chacun peut apporter sa pierre à l'édifice ! La contribution la plus simple consiste à faire la revue de nouveau tickets, et c'est très utile : si vous ne me croyez pas, regardez ce qu'il est écrit :

Jacob Kaplan-Moss (Django BDFL) sur la mailing list django-dev : "this is totally something anyone here can do"
Documentation officielle Django page "contributing" : "there’s a lot that general community members can do to help the triage process"
Documentation officielle de Django page "how contribue" : "Django is a community project, and every contribution helps. We can’t do this without YOU!"

Le cheminement logique et officiel pour devenir un contributeur Django est :

être motivé pour donner un peu de temps en retour à la communauté qui a fait un framework qui me fait vivre !
se créer un compte sur le trac de Django
lire dans l'ordre (ou le désordre) les pages suivantes

Une fois qu'on a lu tout ça, on est prêts à choisir des tickets, soit sur la page Reports de trac, soit sur le super dashbord que Jacob Kaplan-Moss vient de créer.

Mais c'est trop long de tout lire !

Effectivement, il y a beaucoup de ressources, et toutes ne sont pas indispensables pour démarrer.

Pour vraiment débuter, je pense qu'il est indispensable de lire le premier document sur comment contribuer qui a l'avantage d'être assez concis. Il faut ensuite comprendre les différentes étapes d'un ticket, qui sont indiquées sur le deuxième document, dans la section Ticket Triage, avec une image très claire.

Mais c'est trop compliqué, je suis pas assez expérimenté en Django !

Il n'est pas nécessaire d'être un expert pour pouvoir faire de la revue de tickets. Si vous voyez un ticket que vous pensez pouvoir traiter, faites-le, sinon passez au suivant!

Les tickets qui sont en état unreviewed peuvent être fermés, acceptés ou passés en "besoin d'une décision de design" :

Ticket fermé, avec les statuts suivants :

invalid si ce n'est ni un bug, ni une demande d'amélioration, mais une question de support ou sur autre chose que django
duplicate si le même bug ou demande d'amélioration a déjà été signalé. Pour le savoir, il suffit de faire une recherche dans la liste des tickets, puis de fermer le ticket en cours en indiquant que c'est un duplicat du ticket #xxxx
worksforme si vous avez pu tester que ça marche pour vous, avec les informations fournies par le créateur du ticket
needsinfo si il manque des informations pour pouvoir reproduire le bug, mais que le bug a l'air d'être réel

Les autres statuts (fixed et wontfix) ne concernent que les core developers.

Dans tous les cas, lors de la fermeture d'un ticket, il est primordial de rester poli et agréable, en signalant le problème au créateur du ticket, et lui indiquant qu'il peut rouvrir le ticket si il fournit plus d'informations, si on a mal compris le problème...

Il faut garder à l'esprit que le créateur a lui aussi passé du temps pour signaler le problème, et qu'il lui a fallut de la motivation pour faire la démarche de créer ce ticket !

Ticket accepté, avec les indications suivantes :

has patch dans le cas où un patch est fourni (documentation ou code)
needs documentation si il y a un patch pour une fonctionnalité, mais qu'il n'y a pas la documentation qui doit aller avec
needs tests si il y a un patch pour une fonctionnalité sans les tests unitaires nécessaires, ou un patch correctif sans les tests de non régression
patch needs improvement si le patch de documentation n'est pas assez clair ou si le correctif n'est pas acceptable tel quel (possibilité d'améliorations, conformité aux conventions de codage...)
easy pickings pour indiquer que ce ticket peut être facilement et rapidement réglé, même par un débutant (apparaîtra dans une liste personnalisée accessible sur la page report de trac)

Ticket passé en "design decision needed"

C'est le cas notamment des tickets qui proposent des améliorations du framework, ou des corrections de "bug" qui n'en sont pas forcément, ou qui pourraient avoir plusieurs corrections possibles. Une fois le ticket passé en DDN, un des core developers pourra le passer en wontfix ou en accepted.

Et je peux changer le statut de mes propres tickets alors ?

Non.

Pour une réponse plus longue : il vaut toujours mieux au moins une validation externe pour être sûr qu'on a pas oublié quelque chose, ou mal compris la doc, ou fait une typo, ou ...

Trop long, j'ai pas lu

C'est bien dommage. Il faut tout de même un minimum de motivation pour rendre un peu à la communauté de ce qu'elle nous apporte.

J'ai lu, mais tu veux bien résumer ?

Pour débuter et commencer à contribuer, il est très facile de faire de la revue de tickets, c'est-à-dire relire et (in)valider des tickets qui viennent d'être créés.

Dans certains cas, la validation (ou fermeture) du ticket ne nécessitera même pas de test ou de reproduction. Pour les autres, il vaut mieux lire le reste des documents que j'ai listés en début de cet article, ou attendre que je fasse un résumé dans un prochain billet !

Le cadeau bonux

Jacob Kaplan-Moss a lancé une idée pour motiver les revues de tickets : 5 tickets revus, un ticket revu par un des core developers participant à l'opération (Jacob Kaplan-Moss, Alex Gaynor et Carl Meyer).

Donc si vous avez un ticket que vous aimeriez qu'un des core dev considère, vous savez ce qu'il vous reste à faire !

Dans le prochain article, nous verrons comment mettre en place son environnement pour pouvoir contribuer sans douleur !

Djangocong 2011 : une cuvée d'exception

2011-04-21T08:32:00Z

La deuxième conférence Djangocong, organisée par nos cher président (David Larlet) et trésorier (Jean-Michel Armand) a eu lieu ce week-end du 16 au 17 avril 2011, et a regroupé 75 personnes.

Pour rappel, Djangocong est la conférence sur, par et autour de la communauté django française. Le "g" final donne un accent ensoleillé, les deux conférences ayant eu lieu à Marseille.

Vous trouverez dans ce billet mon propre ressenti sur la conférence et je me dois de vous prévenir : j'ai cette année encore apporté ma modeste contribution à l'organisation sur place. Un *etherpad* a été mis à disposition pour regrouper les retours et remarques des présents.

Le format

Le format de cette année, sur l'initiative de David, était articulé autour de trois temps forts :

On a fait (#nowificonfs)

Retours d'expérience de 12 minutes, ces présentations étaient beaucoup plus courtes que ce qu'on peut voir en général. La durée relativement courte a permis aux spectateurs de rester concentrés et attentifs. Par contre, les orateurs ont pour la plupart dû sauter quelques diapos et explications pour respecter les limites de durée.

Format idéal pour des retours d'expériences, mais trop court si ça avait été destiné à des présentations techniques ou de produits.

Lors de cette première matinée, les organisateurs ont décidé d'expérimenter en grandeur nature le "mouvement" lancé par la conférence Sud Web : les conférences sans WiFi.

Le WiFi ayant été désactivé durant toute la durée des présentations, j'ai pu compter en tout 4 ordinateurs ouverts, dont 2 pour des orateurs, sur 75 présents. Pour référence, l'année dernière, sur environ 55 participants, il y avait en moyenne une vingtaines d'ordinateurs ouverts et utilisés pendant les conférences.

Les conséquences ont été multiples:

plus grande attention apportée aux orateurs, mais surtout, plus grand respect (difficile de s'adresser à des têtes baissées et des claviers qui cliquettent)
échanges humains plus poussés : j'ai remarqué une bien moins grande utilisation de twitter par exemple, et plus de discussions informelles (pendant les pauses, les repas, la soirée) sur les sujets présentés, avec ou sans l'orateur d'ailleurs
pas de trending topics ni de retours à chaud, pas d'etherpad rempli à la volée pendant les conférences. Couplé à l'absence de captation vidéo, cela exclu en grande partie les absents qui n'ont finalement que les slides mis en ligne à postériori

Vu que le WiFi a été réactivé le reste de la journée, ainsi que le lendemain, les gens dépendants d'un accès à internet n'ont pas dû être trop lésés.

Idée : limiter l'accès internet à l'intérieur de l'amphi où se déroulent les conférences, mais pas en dehors, par exemple en n'ayant pas de WiFi, mais des connexions filaires. Ou alors ne pas limiter l'accès à internet, mais demander aux spectateurs d'une conférence de ne pas ouvrir leur laptops (pour prendre des notes, il y a le papier+crayon!).

Vous trouverez la liste des liens vers les supports de conférence sur le salon convore dédié et sur le site de la rencontre.

On discute (barcamps)

Une grande première pour moi, et j'en ai été absolument ravi et enthousiasmé. La possibilité de pouvoir échanger à plusieurs, au calme dans une salle, sur un sujet précis, c'est vraiment inestimable.

Ayant dû m'absenter pour aider Jean-Michel à préparer la salle pour le soir, je n'ai pu pleinement participer qu'au barcamp sur "Geeks sans frontières". Ce sera probablement le point de départ d'une communauté de développeurs volontaires pour certains développements, soit d'utilité publique (pour référence, certains avaient participé au sprint sur Memopol), soit dans les cas de force majeure (mise en place d'outils pour trouver des maisons pour abriter des réfugiés suite à un tsunami ou tremblement de terre par exemple).

Il devrait bientôt y avoir une mailing list pour les gens intéressés, à suivre!

Pour l'organisation des barcamps, deux points d'amélioration pour la prochaine édition : l'organisation un poil chaotique (trop organisée selon certains sur l'etherpad), et le manque de salles (l'amphi était à chaque fois utilisé pour un des sujets, et vraiment pas adapté).

J'ai aussi loupé les lightning talks improvisés du samedi soir, je ne pourrais donc pas vous en dire plus.

On fait (sprints)

Après les discussions de la veille lors des barcamps, un petit nombre de sprints ont eu lieu le dimanche matin. Il y avait un grand nombre d'absents, ce qui aurait été dommage et pénalisant pour un orateur si il y avait eu des conférences.

Il y a eu plusieurs sprints, dont un sur les bonnes pratiques pour des applications réutilisables, un autre sur l'intégration des django-floppyforms dans la version 1.4 de django, et je suis sûr qu'il en manque!

Les repas, la soirée

Pour les chanceux ayant pu arriver le vendredi soir, il y a eu un regroupement informel dans une crêperie. Ce fût un moment très agréable et détendu, qui m'a permit de voir pour la première fois (et en avance!) des gens que je côtoie depuis parfois des années sur internet.

Les repas du midi (plateau repas le samedi, sandwich -délicieux- le dimanche) ont été une excellente occasion de se regrouper dans l'herbe au pied de l'école qui nous accueillait, et au soleil!

Le seul petit regret que j'ai pu avoir, c'est de n'avoir pas pu discuter assez (et assez longuement) avec les gens qui étaient là pour la première fois, et qui (pour certains) avaient l'air d'être trop timides pour s'intégrer aux différents petits groupes qui s'étaient formés.

Le samedi soir s'est déroulé à la Bo[a]te non loin du vieux port, dans une ambiance vraiment détendue, et autour d'une énorme paella. La encore, une occasion de pouvoir échanger, discuter, plaisanter, faire mieux connaissance avec des personnes que je croise tous les jours sur internet, et que je ne peux rencontrer en chair et en os qu'une ou deux fois par an.

N'ayant pas pu être présent au parc Longchamp le dimanche après-midi, je n'ai pas eu la chance de voir les poneys ni de manger de la barbapapa!

Conclusion

Pour moi, une édition encore meilleure que la première, et pourtant, c'était pas évident, la première étant déjà excellente! Encore un immense merci à Jean-Michel et David qui se sont décarcassés pour nous concocter cette rencontre! Merci aussi à tous les sponsors sans qui nous n'aurions pas eu à manger, ni une salle aussi agréable pour le samedi midi, ni une salle pour nous accueillir... et une mention spéciale à Jean-Michel (Hybird) et David (Biologeek) qui ont été sponsors en plus d'organiser le tout!

Je repars de cette rencontre avec un sentiment d'appartenance à une communauté (comme joliment écrit par @metamatik), et la hâte d'être à l'année prochaine, pour une édition qui sera sans aucun doute encore meilleure! Et il me faut maintenant jeter un coup d’œil a quelques solutions techniques qu'on m'a fortement recommandées et que je ne connais pas encore : sentry, go-run, jenkins, integrity.

Ils en parlent sur leur blog

J'ai créé un salon convore listant les billets des participants qui font leur retour sur cette rencontre. N'hésitez pas à compléter!

django et le handler500: retourner une erreur 503

2011-04-14T17:04:00Z

Une mise en production ratée ? Un (local) settings oublié ? Un bug inconnu jusqu'alors ?

Dans les trois cas cités, il y a de fortes chances pour que vos utilisateurs voient une erreur 500 (internal server error : erreur interne du serveur). Il est facile, en peaufinant son template 500.html d'afficher un message d'erreur sympatique à l'utilisateur, pour lui expliquer qu'il suffit de patienter, que vous êtes sur la brèche, et que ce bug est en cours de résolution!

En effet, votre serveur de production n'étant pas en DEBUG = True (hein, rassurez-moi), et si vous avez conservé le mécanisme par défaut de django qui vous notifie des erreurs 500 par mail, vous êtes déjà au courant du soucis.

Seulement, si un crawl bot (robot indexeur) passe par là, il va tomber sur une page (ou plusieurs) qui ne fonctionne(nt) pas. Je ne sais pas quel est l'impact sur le classement de votre site, mais ce qui est sûr, c'est que ce genre d'erreur (ainsi que les erreurs 4xx) ne peut avoir qu'un impact négatif.

Heureusement, il existe le code d'erreur 503 (service unavailable : service indisponible) qui permet de spécifier un header Retry-After (réessayer après), avec une durée ou une date.

Voici comment détourner le handler500 fournit par défaut par django, pour renvoyer un code d'erreur 503, et le header associé, dans notre cas, un Retry-After d'une heure :

Créer son propre handler

Pour celà, créer par exemple le fichier utils/handlers.py :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from django import http
from django.views.decorators.csrf import requires_csrf_token
from django.template import Context, loader

class MyHttpResponseServerError(http.HttpResponse):
    status_code = 503

    def __init__(self, *args, **kwargs):
        http.HttpResponse.__init__(self, *args, **kwargs)
        self['Retry-After'] = '3600'

@requires_csrf_token
def handler500(request, template_name='500.html'):
    """Error handler that returns a 503 status code and a Retry-After header.

    Returning a 503 error code will tell crawl bots to retry later.

    """
    t = loader.get_template(template_name)
    return MyHttpResponseServerError(t.render(Context({})))

Détourner le handler500 par défaut

Et maintenant, il suffit de spécifier dans son ROOT URLCONF (le fichier urls.py à la racine du projet) :

handler500 = 'utils.handlers.handler500'

Conclusion

Il est difficile de savoir si retourner un statut 503 est préférable à un statut 500, en particulier sur le ranking dans les moteurs de recherche. Il y a bien une réponse (approchante) d'un employé de Google qui laisse penser qu'un 503 est recommandé. Dans tous les cas, je trouve plus sympa et propre d'avoir une erreur indiquant clairement que c'est un soucis temporaire, avec un ordre d'idée du délai avant de réessayer de visiter cette url.

Qu'en pensez-vous?

La technique pomodoro : retour après plus d'un mois d'utilisation

2011-04-04T09:58:00Z

Ça y est, j'ai franchi la barre (fatidique?) de un mois d'utilisation de ma nouvelle habitude, ce qui, selon certains, en fait une habitude durable.

Je me fends donc d'un billet, suite à l'article précédent: La technique pomodoro : retour après deux semaines d’utilisation.

Reprenons les points principaux de mon précédent billet:

Les points positifs

La gestion des interruptions

Un des deux points principaux dans mon utilisation de cette technique, mais avec une petite modification : un pomodoro entammé m'aide à me concentrer sur ma tâche en cours, et à ne pas être interrompu par toutes les notifications "sociales sur le web" (mail, twitter, skype, irc...). Par contre, je me suis rendu à l'évidence, elle ne me permet pas de me protéger des interruptions réelles, telles que coups de téléphone, coup de sonnette à la porte, ...

Lors d'une interruption IRL, je distingue plusieurs cas:

interruption pour le travail liée à ma tâche en cours : coup de téléphone pour un retour de test où une question sur mon projet en cours
interruption pour le travail non liée à ma tâche en cours, mais très courte et ne nécessitant pas de réflexion intellectuelle : coup de téléphone me demandant si j'ai bien reçu un courrier, demande de précision sur un autre projet...
interruption non liée au travail

Dans le premier cas, je n'interromps pas le pomodoro, voire même j'enchaîne sur un autre pomodoro immédiatement après (en zappant la pause) si nécessaire.

Dans les deux derniers cas, je met le pomodoro en pause, et je le reprends une fois l'interruption terminée

Comptabiliser le temps passé, aide à l'estimation d'une tâche

Avec le point précédent, le plus grand avantage que j'y trouve dans mon utilisation de cette technique : j'ai regroupés les deux points, vu qu'ils me semblent vraiment liés. Je tiens le compte du temps que j'ai passé sur telle ou telle tâche, ce qui peut me servir pour un compte rendu, ou par la suite pour ajuster mes estimations.

Après plus d'un mois d'utilisation, je commence à voir les points sur lesquels il faut que j'ajuste mes estimations, et ceux sur lesquels j'ai assez d'expérience et de retour pour coller au plus proche de la réalité.

Aide à l’organisation

Même si, comme je l'indiquais précédemment, la technique pomodoro n'est pas à proprement parler la technique GTD, elle me permet d'avoir une liste de tâches à faire (à plus ou moins long terme), une sorte de pense-bête, et une autre liste pour les tâches "en cours", à réaliser dans la journée ou à très court terme.

Les points négatifs

Les 25 minutes de Pomodoro

J'hésite beaucoup moins à présent à stopper la tâche en cours, qui me demanderait "juste une minute de plus", pour prendre ma pause, puis enchaîner sur un nouveau pomodoro. En effet, un pomodoro effectué est une victoire, pas un échec, cf ci-après.

Les pauses

J'en parlais, et je persiste et signe : les pauses sont importantes, pour plusieurs raisons

savoir qu'on a une pause dans X minutes permet de garder sa concentration sur la tâche en cours, et motive pour ne pas craquer et succomber aux notifications et interruptions diverses
une pause permet de souffler un peu, détendre les muscles de ses épaules, jeter un oeil par la fenêtre, et par la même occasion faire travailler les muscles occulaires
combattre l'effet "tête dans le guidon" : je ne pense pas être le seul dans ce cas. Lors d'un développement, il arrive qu'on se focalise sur une solution, une implémentation, et une fois terminé, on se rends compte qu'il existait une solution bien plus élégante et/ou simple. Eh bien toutes les 30 minutes, on a une chance de s'en rendre compte avant d'y avoir passé une journée !

Les interruptions

Voir les points positifs sur ce sujet : plutôt que de m'échiner à me protéger des interruptions IRL, j'ai préféré faire avec et adapter la technique à mes besoins.

Le pomodoro effectué est une victoire, pas un échec

L'avoir écrit m'a permit de le réaliser lors de la rédaction de mon précédent billet. La méthode du rubber ducking victorieuse à nouveau!

Les points à travailler

J'avais listé les points suivants:

respect des pauses
ressenti de la fin d'un pomodoro qui doit être positif
gestion des interruptions
utilisation de la technique en télé-travail

Au vu de ce que j'ai écrit plus haut, je pense avoir trouvé la solution qui me convenait pour chacun de ces points. Respect des pauses et ressenti d'un pomodoro effectué allant de pair, et gestion des interruptions "souple" qui me permet de ne pas gaspiller mon énergie à aller à contre courant.

Conclusion

Cette technique, avec les quelques adaptations que j'y ai apportées pour coller au mieux à ma méthode de travail, me convient parfaitement. Je pense m'être un peu écarté de la philosophie de la technique officielle, en n'annulant pas un pomodoro interrompu par une interruption IRL, mais je suis content de pouvoir à présent mieux gérer et suivre mon temps de travail effectif et productif.

La gestion des interruptions "sociales" me permet aussi d'optimiser mon temps de travail, et d'améliorer le rapport "travail effectif" / "temps passé devant l'ordinateur".

Quelques chiffres:

reccord de pomodoros dans une journée : 22
reccord de pomodoros sur deux jours de week-end : 15
moyenne de pomodoros en semaine : 11
moyenne de pomodoros les jours avec 2 tâches ou moins : 12.4
moyenne de pomodoros les jours avec 3 tâches : 11
moyenne de pomodoros les jours avec 4 tâches ou plus :10.2

Il semblerait donc, après un mois d'utilisation, que ce qui joue sur le nombre de pomodoros par jour soit le nombre de tâches différentes à effectuer par jour, et donc le nombre de fois où il faut que je fasse un changement de contexte. Changer de tâches régulièrement n'est pas anodin, et conforte ma croyance que le cerveau n'est pas multi-tâche (hein No`!).

Mais plus que le nombre de tâches par jour, je pense que c'est l'état de fatigue nerveuse qui influe le plus. Après une semaine à faire en moyenne 15 pomodoros par jour (et un reccord de 22), je sens que les jours à venir vont devoir être plus détendus.

Et si il y a un seul élément à retenir et à surveiller, c'est le sommeil. Une journée sans avoir assez dormi la veille sera une journée molle, avec beaucoup de mal pour me concentrer, et une bien plus grande tentation de papillonner au gré des notifications. Depuis maintenant deux semaines, j'ai changé mon rythme de sommeil, et ne met plus mon réveil le matin. Je dors donc entre 8 et 9h par nuit, et je me sens beaucoup plus efficace dans la journée ! Ce sera peut-être le thème d'un futur billet ;)

Ce billet a été écrit en deux pomodoros complets, non interrompus.

La technique pomodoro : retour après deux semaines d'utilisation

2011-03-02T16:35:00Z

Voici deux semaines maintenant que j'ai décidé d'essayer la technique Pomodoro de gestion du temps. En attendant le retour d'expérience au bout d'un mois (cf le 30 days to success), voici déjà mes réflexions à mi-chemin.

Le principe

Il est simple, très simple, et c'est d'ailleurs un des points forts de cette technique : la facilité de compréhension et de mise en œuvre.

Voici la traduction de ce qu'on peut trouver sur la page d'accueil du site de la technique :

choisir une tâche à accomplir
régler le Pomodoro sur 25 minutes (le Pomodoro est le minuteur)
travailler sur la tâche jusqu'à ce que le Pomodoro sonne, et faire une croix sur une feuille de papier
faire une courte pause (5 minutes)
tous les 4 Pomodoros, faire une pause plus longue (30 minutes)

On peut ensuite rajouter quelques points à faire dans la journée :

tenir une liste à jour de toutes les tâches à faire
chaque début de journée, choisir les tâches à faire pour la journée en cours, et estimer le nombre de Pomodoros nécessaires pour chacune
en fin de journée, faire le compte du nombre de Pomodoros effectués dans la journée, faire le point sur les estimations
lors d'une interruption
- si c'est possible, la noter sur une feuille "interruptions et imprévus", et s'en occuper à la fin d'un Pomodoro
- si il faut s'en occuper de suite, le Pomodoro en cours est perdu, et ne doit pas être comptabilisé

Les points positifs

Commençons par les bons côtés :

La gestion des interruptions

Et c'est pour ce point en particulier que je comptais sur la technique Pomodoro, et je ne suis pas déçu. De nos jours, surtout si on est présents sur les réseaux sociaux (twitter pour ma part), sur irc, qu'on suit des flux RSS, ou même seulement si on surveille ses mails, on est baignés dans un flot d'informations. Ce flot n'est pas passif, puis qu'il y a de très nombreuses notifications possibles, entre celles du navigateur, de clients divers, de "highlights" irc...

Or là, la règle est simple : pendant un Pomodoro, on reste concentré sur la tâche qu'on s'est assignée, et on ignore les notifications. Et il est beaucoup plus facile de les ignorer si on sait qu'on pourra y succomber dans x minutes. Dès lors, on travaille d'une traite pendant 25 minutes, et la productivité augmente.

Comptabiliser le temps passé

Rien de plus facile : en fin de journée, il suffit d'additionner les petites croix tracées sur sa feuille pour savoir qu'on a travaillé n * 30 minutes. Je compte toujours les 5 minutes de pause dans le temps de travail, car sans ces pauses, il ne serait pas possible de rester concentré et productif. De la même manière qu'un employé de bureau ou un ouvrier ne va pas décompter ses pauses café, je ne décompte pas ces pauses qui sont, j'en suis persuadé, indispensables au bon déroulement d'une journée de travail.

Aide à l'estimation de la durée d'une tâche

En temps qu'informaticien, on me demande constamment des estimations de durées : que ce soit pour régler un problème, implémenter une nouvelle fonctionnalité, expérimenter de nouvelles solutions ... et ce, pour un devis, pour avoir une date de mise en production ...

Lorsque je rajoute une tâche dans ma liste, j'y met une estimation en nombre de Pomodoros. Je peux ainsi voir les écarts entre cette estimation et le temps qu'il m'a fallut en réalité en fin de journée. Et j'ai bon espoir que cet écart baisse avec l'exercice !

Aide à l'organisation

J'imagine que tout le monde à déjà entendu parler du GTD, cette méthode qui permet de s'organiser afin de "faire les choses". Eh bien avec la technique Pomodoro, j'ai déjà une liste de tâches à faire, et une liste de tâches que j'ai prévues pour la journée. Il y a pas mal de points communs, et je pense que les adeptes de la méthode GTD peuvent y trouver leur compte.

Les points négatifs

Du côté des points négatifs, voici ceux que j'ai pu lister jusqu'à présent. Je n'utilise la technique que depuis deux petites semaines, et concerne principalement les soucis que j'ai rencontrés lors de l'application de la technique à mon emploi en télé-travail.

Les 25 minutes de Pomodoro

25 minutes de travail, de concentration, puis 5 minutes de pause. Et 30 minutes de pause toutes les deux heures. Sauf que c'est pas toujours aussi évident.

Je me retrouve sans cesse confronté à des tâches qui me demandent "juste une minute de plus". Une minute de plus pour envoyer un mail de notification suite à un problème résolu. Ou une minute de plus pour mettre en production une fois que tous les tests sont passés. Je dis une minute, mais ça peut être 2 minutes, voire 5 ... où s'arrêter ? A quel point il faudrait plutôt faire une pause, et y passer un Pomodoro de plus ?

Lorsqu'une tâche est plus courte qu'un Pomodoro, il est conseillé de "sur-apprendre", de mettre à profit ce temps pour perfectionner son geste. Il m'est arrivé, pour un Pomodoro où il me restait 15 minutes, de refaire mon système de déploiement (merci Fabric). Super ! sauf que du coup j'ai enchaîné sur un Pomodoro supplémentaire (non prévu en début de journée), pour finaliser la réécriture de mon fabfile.

Les pauses

Pour continuer sur le point précédent, je trouve ça parfois très dur de prendre la pause de 5 minutes. Si je suis concentré, dans le flow, il m'est très difficile de m'interrompre pour cette pause.

Si il ne manque qu'une minute, je suis tenté de continuer pour terminer (et je le fais très souvent). Si je suis vraiment bien lancé, j'ai parfois peur que la consultation de mes mails/irc/twitter/rss me déconcentrent, me fassent sortir de mes rails, et que du coup ce soit plus difficile de m'y remettre pour terminer ce que j'avais commencé.

Travaillant de la maison, je n'ai toujours pas réussi à respecter les pauses de 30 minutes. Comme il m'arrive de devoir travailler sur des tâches non prévues, et trop courtes pour mériter un Pomodoro (réponse à un mail pro par exemple), je déborde sur les pauses de 5 minutes, en me disant que je me rattraperais avec ma pause repas par exemple.

Dans d'autres cas, j'arrête tout simplement le timer à la fin d'un Pomodoro (pause repas, vaisselle, allumer un feu...), et je zappe la pause (de 5 minutes ou de 30 minutes, selon les cas). Mais du coup, je pense perdre les avantages et la satisfaction de l'enchaînement de Pomodoros.

Les interruptions

Je suis en télé-travail, et il m'arrive, en général deux ou trois fois dans la journée, d'avoir des interruptions de collègues de travail qui ont besoin de moi. Ce peut être par skype ou téléphone, et c'est en général difficile à reléguer à la fin d'un Pomodoro : si il me reste 15 minutes avant la fin, je ne peux pas "mettre en pause" mon collègue qui a ses tâches à lui.

Ces interruptions peuvent être très courtes (quel est mon mot de passe pour le serveur bidule?), ou plus ou moins longues (on a un serveur en rade, tu peux t'y coller de suite?). Que faire dans ce cas ? En théorie, je dois interrompre mon Pomodoro et le "perdre", mais du coup je ne peux plus me servir du nombre de Pomodoros effectués dans la journée pour suivre le temps travaillé, et il me faut alors me servir d'un outil supplémentaire (le projet hamster par exemple).

Pour le moment en tout cas, je met le minuteur en pause, et le recommence après l'interruption, si elle a été assez courte et assez peu "mentale" pour ne pas m'avoir déconcentré.

Le pomodoro effectué est une victoire, pas un échec

En tout cas, en théorie, c'est comme ça que je devrais le ressentir. Le slogan de la technique Pomodoro, c'est de faire du temps un allié. Or quand je vois que je viens de finir un Pomodoro (de plus!) sur une tâche que j'avais sous-estimée, je culpabilise. Et je rechigne à repartir pour un Pomodoro supplémentaire.

Il faut que j'apprenne à voir un Pomodoro effectué comme une réalisation, une victoire, une bonne chose de faite. Et si j'ai sous-estimé la tâche, que cela me serve de leçon pour la prochaine.

Les points à travailler

Il me reste encore deux bonnes semaines avant mon prochain point et retour sur expérience. D'ici là, il faut que je travaille sur :

le respect des pauses : comme je l'indiquais en début de ce billet, je compte les 5 minutes de pause dans mon temps de travail, et je suis persuadé qu'elles sont indispensables. J'ai plus de mal avec les pauses de 30 minutes, et c'est là-dessus qu'il faut que je mette le paquet
ressenti de la fin d'un pomodoro qui doit être positif
gestion des interruptions : il faut que je prenne au moins une note de chacune des interruptions que je n'ai pu remettre, même si je ne "perds" pas systématiquement le Pomodoro en court. Une croix pour chaque fois que je dois mettre le minuteur en pause, retour dans 15 jours ;)
utilisation de la technique quand on est en télé-travail : est-ce qu'il y aurait un moyen d'indiquer, par exemple par un statut ou un indicatif de présence (skype, irc...) à mes collègue de travail que je suis en cours de Pomodoro ? à creuser...

Je sais qu'il y a au moins une personne qui serait intéressée par le dernier point : @dzen a plusieurs fois émis l'idée de synchroniser les Pomodoros entre utilisateurs du salon irc ;)

Conclusion

On m'avait prévenu, mais j'ai quand même été surpris : on fait beaucoup moins de pomodoros qu'on imagine ! Je me met devant le PC vers 6h le matin, et j'arrête ma journée de travail vers 20h (quand ça se passe bien ;). Je dois donc passer plus de 12h devant le pc, et en comptant large sur les pauses et interruptions, je pensais être productif au moins pendant 8 à 9 heures.

Et bien au final, sur les deux semaines passées, je suis en général entre 10 à 12 Pomodoros par jour, si je ne compte que les 5 jours de semaine. Ce qui fait donc entre 5 et 6 heures de productivité par jour.

A cela il faut bien entendu rajouter toutes les interruptions téléphoniques, le temps passé à répondre aux mails, la comptabilité... toutes ces tâches que je ne me vois pas (pour l'instant?) consigner dans des Pomodoros, mais que du coup, je ne compte pas non plus dans mon "temps travaillé" en fin de journée.

Ah, et pour les malins qui me diront que le pluriel de Pomodoro, c'est Pomodori, je leur répondrais que :

on peut soit utiliser pomodori soit pomidoro
sur le site officiel, ils utilisent pomodoros
je fais bien ce que je veux, na!

Ce billet a été écrit en

3 Pomodoros complet avec 2 micro-interruptions
1 Pomodoro interrompu (4 fois!)

django: redimensionner une image à la volée en préservant son ratio

2011-02-16T13:15:00Z

Une rapide recherche sur "django image thumbnail" vous sortira très vraisemblablement de nombreuses solutions : snippets, applications, astuces... en particulier la page Thumbnails sur le wiki de django qui liste beaucoup de solutions et leurs avantages.

Voulant faire simple, et profiter de toutes les améliorations que j'ai pu trouver et compulser sur diverses solutions, voilà ma contribution.

Utiliser PIL et Image.thumbnail()

Python Image Library est une des (la?) solutions les plus avancées sur le traitement d'image en python. Dans mon cas pratique, je veux, lors d'un upload d'une photo, pouvoir :

redimensionner la photo, pour qu'elle fasse au maximum 800x600 : elle sera affichée avec un max-width et un max-height
créer un thumbnail
stocker les images au format jpg
tout ceci sans au préalable sauver l'image sur le disque

Beaucoup des solutions que j'ai pu trouver utilisaient la fonction resize() de PIL.Image, et utilisaient un calcul du ratio pour conserver l'aspect de l'image. Heureusement, PIL a pensé au fainéant que je suis, et fournit la fonction thumbnail() qui va automatiquement redimensionner l'image pour qu'elle rentre dans les dimensions maximales qu'on lui fournit.

Le modèle

Modèle très simple pour illustrer notre propos :

class Foo(models.Model):
    photo = models.ImageField(upload_to='photos/')
    thumbnail = models.ImageField(upload_to='photos/thumbs/')
    legend = models.CharField(max_length=50)

La solution

Cette solution est largement inspirée de cet article qui collait le plus à la version que je souhaitais obtenir au final : generate thumbnails in django with PIL.

Tout d'abord le morceau de code qui récupère l'image en mémoire (stockée dans un InMemoryUploadedFile) et la converti en mode RGB si nécessaire :

from PIL import Image
from cStringIO import StringIO
from django.core.files.uploadedfile import SimpleUploadedFile

...

    def save(self, *args, **kwargs):
        if has_changed(self, 'photo'):
            # on va convertir l'image en jpg
            filename = path.splitext(path.split(self.photo.name)[-1])[0]
            filename = "%s.jpg" % filename

            image = Image.open(self.photo.file)

            if image.mode not in ('L', 'RGB'):
                image = image.convert('RGB')

            # d'abord la photo elle-même
            self.photo.save(
                    filename,
                    create_thumb(image, settings.IMAGE_MAX_SIZE),
                    save=False)

            # puis le thumbnail
            self.thumbnail.save(
                    '_%s' % filename,
                    create_thumb(image, settings.THUMB_MAX_SIZE),
                    save=False)

Et enfin la fonction create_thumb qui prends en paramètre une PIL.Image et une taille du style (800, 600) :

def create_thumb(image, size):
    """Returns the image resized to fit inside a box of the given size"""
    image.thumbnail(size, Image.ANTIALIAS)
    temp = StringIO()
    image.save(temp, 'jpeg')
    temp.seek(0)
    return SimpleUploadedFile('temp', temp.read())

Retourner un SimpleUploadedFile permet de le fournir directement au save() de l'ImageField.

Le bonus

Vous avez sûrement remarqué la fonction has_changed() dans l'appel de la méthode save() ci-dessus... en effet, il serait peu utile, voire même carrément indésirable de générer une nouvelle version de la photo et de son thumbnail à chaque fois que notre modèle est sauvé!

On se retrouverait vite avec autant de photos et de thumbnails que le nombre de fois qu'on a sauvé notre modèle, même si la seule modification portait sur la légende.

Pour limiter ça, on ne redimensionne et génère le thumbnail que si la photo a été modifiée, ce qu'on teste avec la fonction suivante :

def has_changed(instance, field, manager='objects'):
    """Returns true if a field has changed in a model

    May be used in a model.save() method.

    """
    if not instance.pk:
        return True
    manager = getattr(instance.__class__, manager)
    old = getattr(manager.get(pk=instance.pk), field)
    return not getattr(instance, field) == old

Django forms, HTML5 et fieldsets

2011-02-11T22:56:00Z

J'adore l'open-source, et j'adore le libre.

Aujourd'hui, à 20h30, je me dis que j'aimerais bien pouvoir utiliser les nouveaux form input de HTML5 dans mes formulaires django. Je me rappelle alors de l'excellent django-floppyforms de ce cher Bruno Renié.

django-floppy-forms : la librairie de widgets

Quelques minutes et un pip install django-floppyforms plus tard, je me retrouve avec un petit formulaire de test :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import floppyforms as forms


class TestForm(forms.Form):
    name = forms.CharField()
    email = forms.EmailField(widget=forms.EmailInput(attrs={'placeholder': 'john@example.com'}))
    url = forms.URLField()

Ce qui me donne le résultat visuel suivant :

On y voit bien le placeholder dans le champ de type email. Sur l'image suivante, on voit la validation faite directement au niveau du browser (firefox 4b11) :

A 20h45 : "ce que j'aimerais vraiment bien, c'est pouvoir scinder mon formulaire en fieldsets, comme le permet l'administration de django". Va-t-il falloir que je me mette à développer? Que nenni, cher lecteur, comme tu l'aura deviné, un autre développeur de talent, un certain Carl Meyer nous propose le très pratique django-form-utils.

django-form-utils : une méthode propre pour spécifier des fieldsets

Encore quelques minutes et un pip install django-form-utils plus tard, voici le code du formulaire :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import floppyforms as forms
from form_utils.forms import BetterForm


class TestForm(BetterForm):
    name = forms.CharField()
    email = forms.EmailField(widget=forms.EmailInput(
                attrs={'placeholder': 'john@example.com'}))
    url = forms.URLField()

    class Meta:
        fieldsets = [
            ('test', {
                'fields': ['name', 'email'],
                'legend': 'a test legend',
            }),
            ('other test', {
                'fields': ['url'],
                'description': 'a test description',
                'classes': ['advanced', 'collapse']
            }),
        ]
        row_attrs = {'name': {'style': 'background: #f00'}}

Et le template, un poil plus complexe que le {{ form.as_p }} précédent :

{% if form.non_field_errors %}{{ form.non_field_errors }}{% endif %}
{% for fieldset in form.fieldsets %}
<fieldset class="{{ fieldset.classes }}">
    {% if fieldset.legend %}<legend>{{ fieldset.legend }}</legend>{% endif %}
    {% if fieldset.description %}
        <p class="description">{{ fieldset.description }}</p>
    {% endif %}
    {% for field in fieldset %}
        {% if field.is_hidden %}
            {{ field }}
        {% else %}
            <p{{ field.row_attrs }}>
                {{ field.errors }}
                {{ field.label_tag }}
                {{ field }}
            </p>
        {% endif %}
    {% endfor %}
</fieldset>
{% endfor %}

Et voici le résultat (les moqueurs reconnaîtrons mon talent pour tout ce qui touche au design) :

21h00 : Tout ça est vraiment super. Mais... quitte a être exigeant, est-ce que je pourrai avoir des fieldsets ET un template plus simple? Par exemple un layout générique du style uni-form... c'est là que Daniel Greenfeld entre en jeu avec son projet pour djangonautes fainéants django-uni-form.

django-uni-form: les uni-forms pour django

Vous connaissez le refrain, quelques minutes et un pip install django-uni-form plus tard :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import floppyforms as forms
from django.forms import Form
from uni_form.helpers import FormHelper, Submit
from uni_form.helpers import Layout, Fieldset


class TestForm(Form):
    name = forms.CharField()
    email = forms.EmailField(widget=forms.EmailInput(
                attrs={'placeholder': 'john@example.com'}))
    url = forms.URLField()
    helper = FormHelper()
    layout = Layout(Fieldset('a test legend', 'name', 'email'),
                    Fieldset('other test', 'url'))
    helper.add_layout(layout)
    submit = Submit('submit','test this form')
    helper.add_input(submit)

Et le template, beaucoup plus simple du coup :

{% load uni_form_tags %}
{% with form.helper as helper %}
    {% uni_form form helper %}
{% endwith %}

Conclusion

Il fait bon être fainéant, utiliser django, et les outils déjà disponibles en open-source. Les applications que j'ai présentées ici ont été bien pensées, et sont pluggable : on peut facilement les rajouter à son projet et les utiliser ou même les combiner!

Dans notre cas on a pu tester l'utilisation de widgets html5 (django-floppy-forms) avec un layout par fieldset défini dans la class Meta du formulaire (django-form-utils), ou grâce à un helper (django-uni-form).

Pour le moment mon cœur balance entre les deux, la solution utilisant la sous-class Meta me paraissant plus naturelle, mais l'utilisation d'un layout robuste et soigné comme les uni-form étant plus simple, "standard" et économisant plus de temps.

A quand un projet permettant d'hériter d'une classe UniForm, dans laquelle on définit les fieldsets dans une sous-classe Meta ?

Ah, au fait, de 21h00 à 23h00, écriture de ce billet... une demi heure pour tester trois projets, et presque deux heures pour en parler, personne n'aurait une pluggable app qui pond des billets ?

Double encodage utf8 : afficher correctement avec python et django

2010-12-27T16:39:00Z

Nous avons vu dans un précédent article qu'il pouvait y avoir des soucis de double encodage utf8, par exemple pour des textes stockés dans une base de donnée.

Imaginons, un court instant (parce que plus longtemps que ça, ce serait bien trop douloureux hein ;)), que nous ayons une base de donnée avec certains champs de certaines tables qui sont doublement encodés en UTF-8, par exemple le champ name.

Le problème

Voici à quoi ressemblerait le modèle Django d'une telle table :

class Foo(models.Model):
    name = models.CharField(max_length=70)

    def __unicode__(self):
         return self.name

Et voici un exemple d'affichage (dans l'admin) du nom d'un tel modèle : HelicoptÃ¨re

En effet, Hélicoptère, représenté en utf8 par Helicopt\xe8re, est stocké en latin1 par MySQL, et donc renvoyé (doublement) encodé en utf8 sous la forme Helicopt\xc3\xa8re.

La solution

Puisque la donnée est doublement encodée, il suffit de la décoder une fois :

>>> f = Foo.objects.get(name__startswith='Helico')
>>> f.name
u'Helicopt\xc3\xa8re'
>>> f.name.encode('latin1')
'Helicopt\xc3\xa8re'
>>> f.name.encode('latin1').decode('utf8')
u'Helicopt\xe8re'

Et le tour est joué!

Un affichage (presque) propre avec django

Dans django, il est possible de spécifier une méthode __unicode__ sur un modèle, pour gérer son affichage par défaut, qui est utilisé notamment dans l'affichage des listes d'objets d'un modèle, dans l'administration.

Nous pouvons donc modifier la méthode de notre modèle indiqué en début de cet article :

def __unicode__(self):
     return self.name.encode('latin1').decode('utf8')

Mais... tout n'est pas parfait

Il faut penser aux points suivants :

il faut bien utiliser __unicode__ à la place de name partout où c'est possible, par exemple si on spécifie un list_display dans le ModelAdmin
lorsqu'on éditera l'objet, le name doublement encodé apparaîtra, et si on le modifie manuellement pour s'afficher correctement, on aura une incohérence dans la table, avec des données doublement encodées, et d'autres stockées correctement

Une autre méthode

Il est possible de spécifier des options lors de la connexion à la DB MySQL, avec django, pour lui demander d'utiliser le charset latin1. Vu que django lui-même ne parle qu'en utf8, demander à MySQL des données en latin1 revient à lui demander de ne pas ré-encoder la donnée qu'il pense être stockée en latin1, mais qui sera ensuite correctement affichée par django :

DATABASES = {
    'hack': {
        'NAME': 'bar',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'baz',
        'PASSWORD': 'bizbaz',
        'HOST': 'localhost',
        'PORT': '',
        'OPTIONS': {
            'charset': 'latin1',
            'use_unicode': False,
        },
    },
}

L'avantage ici est qu'il n'y a pas besoin d'avoir un traitement spécifique des données, par exemple dans la méthode __unicode__, et que toutes les données lues seront dé-doublement-encodées (!?).

Le gros inconvénient est que toutes les tables subiront le même traitement, même celles qui ont un encodage et stockage correct. L'utilisation d'un routeur et d'une deuxième entrée dans les DATABASES uniquement pour les tables ayant un soucis n'étant pas une solution durable non plus, car celà limite les relations entre tables.

Et tant qu'à faire dans le crade

La solution la plus dangereuse serait d'avoir un traitement "par défaut" de toutes les données qu'on veut afficher, pour :

régler le problème du double-encodage si il y en a un
afficher la donnée brute si on ne peut pas dé-double-encoder

Exemple :

def __unicode__(self):
    try:
        return self.name.encode('latin1').decode('utf8')
    except:
        return self.name

On ne se pose alors plus la question de la cohérence des données et de leur encodate et stockage dans la base de donnée, mais on se met à dos une énorme dette technique : le développement du traitement spécifique de toutes les colonnes de toutes les tables le nécessitant peut être titanesque, et bien plus lourd que la correction du problème à la base.

Conclusion

Rien ne vaut une DB saine, ses tables étant toutes encodées correctement. Si vous commencez à utiliser des workarounds ou hacks divers, vous vous en mordrez les doigts (il me manque déjà plusieurs phalanges, croyez-moi).

La dette technique (métaphore inventée par Ward Cunningham) est une plaie dont il faut se préserver au maximum, et qu'il faut rembourser le plus tôt possible.

La vie a la couleur qu'on veut bien lui donner

2010-11-15T08:53:00Z

Ce billet n'est pas technique, il est une manière pour moi de mettre par écrit, mettre en mots, un état d'esprit, une réflexion sur ma propension a râler et rouspéter à la moindre occasion.

Je suis un râleur

Je le sais, je le reconnais, et ce depuis longtemps. Ce que je ne sais pas, c'est pourquoi.

Je pense avoir toujours eu de la chance, moins que d'autres sûrement, mais bien plus, infiniment plus que d'autres : SDF, exclus, souffrants d'un handicap, rejetés par leur famille (peut-être le plus grand des malheurs?), torturés, génocidés (je suis d'origine arménienne), victimes de la famine, d'épurations ethniques, d'ouragans, de guerres civiles, de despotes et dictateurs en tous genre...

Mon empathie me fait souvent souffrir pour les victimes d'injustices, les laissés pour comptes, les galériens qui trimeront toute leur vie pour ne pas arriver à subvenir à leurs besoins et ceux de leur famille.

De mon côté, j'ai eu une enfance vraiment dorée, entouré de parents aimants et de trois petites sœurs adorables. Je n'ai jamais manqué d'un toit ni de nourriture. Même si nous n'étions pas aisés, je n'ai jamais ressenti le moindre besoin.

Je suis maintenant (jeune) marié à une femme extraordinaire, que j'aime et qui m'aime (peut-être le plus grand des bonheurs?).

Mais je râle gentiment

Suite à une discussion ce matin avec un ami, qui me relance régulièrement pour que j'écrive un polar geek, je me suis remis en question. Voici notre échange :

<magopian> voilà pourquoi je ne sais pas écrire de nouvelles :
    ça finirait en rouspétage
<magopian> j'ai pas envie qu'on m'appelle le caliméro du polar geek ^^
<J-Mad> ben ca pourrait être une idée cool de perso
<J-Mad> un gros râleur
<J-Mad> qui râle pour tout
<J-Mad> un de mes amis est comme ça
<J-Mad> quand il rale pour des trucs insignifiants
<J-Mad> on sait que tout va bien, qu'il faut juste qu'il râle sur un truc

Un râleur continuel, le rouspéteur de service. Ce gars dont les révoltes ne sont qu'une expression naturelle de sa personnalité, une image de bougon, pas renfrogné mais facilement revendicateur.

Un gars sympa quoi, pas méchant, plutôt agréable, et un peu marrant avec ses coups de gueule et ses logorrhées inutiles.

Vraiment?

Mais alors, si j'ai autant de chance, de bonheur, si j'aime autant être de bonne humeur, rire, communiquer, partager, profiter, pourquoi râler?

Pourquoi véhiculer la mauvaise humeur, la rancoeur, la colère même? Je sais pourtant qu'un état d'humeur, que les sentiments sont contagieux. Pourquoi alors, ne pas véhiculer la joie de vivre et la motivation?

La vie a la couleur qu'on veut bien lui donner

Voilà la phrase, toute simple et pourtant lourde de (bonnes) conséquences, qu'une charmante dame m'a confié comme "astuce de bonheur". Une dame frappée par les malheurs, et qui pourtant a toujours le sourire aux lèvres.

"Moi, je veux la voir en rose, pas besoins de lunettes teintées d'enfant pour ça, c'est juste un état d'esprit!" m'a-t'elle confié.

Et bien moi aussi, je veux la voir en rose (en poney rose même, hein Zébuline ;)

lancer gunicorn avec supervisord

2010-08-31T16:48:00Z

Après avoir mis en place une méthode pour lancer gunicorn avec runit, voici un second article pour lancer ce même gunicorn (qui poutre du poney, rappelons-le), mais avec un outil que je trouve à l'utilisation bien plus pratique : supervisord

Pourquoi supervisord et pas runit ?

Après l'avoir utilisé sans aucun soucis depuis quelques temps sur le serveur de secours de notre site web, je trouve que supervisord est plus convivial à utiliser, et plus "clair" à mettre en place.

Plus convivial à utiliser parce qu'il a un client CLI qui permet d'interagir directement avec les processus monitorés, mais il y a aussi les mêmes fonctionnalités par le biais d'une interface web fort pratique.

Plus "clair" à mettre en place parce qu'il se lance grâce à un simple script d'init, et qu'on peut faire la configuration de tous ses processus à monitorer dans un seul et même fichier de configuration, au lieu d'avoir un répertoire et des liens symboliques à gérer (certains préfèrent peut-être cette modularité, mais personnellement je trouve ça beaucoup plus pénible à maintenir).

Installer supervisord

Etant donné que supervisord est en python, il est possible de l'installer avec un simple

$ pip install supervisor

Pour les old-school qui ne profitent pas encore de la puissance et de l'ergonomie de ce magnifique outil de Ian Bicking, il est possible de remplacer pip par easy_install (même si je vous conseille plutôt de faire un easy_install pip puis de vous passer de easy_install par la suite!).

Configurer supervisord

On le configure en deux temps : une première configuration de supervisord lui-même, puis l'ajout des processus qu'on veut qu'il monitore.

Dans le fichier /etc/supervisord.conf :

; configuration de supervisord lui-meme
[unix_http_server]
file=/tmp/supervisor.sock   ; chemin vers le fichier socket

[inet_http_server]
port=192.168.0.21:9001      ; adresse ip _LOCALE_ de la machine pour la connection web

[supervisord]
logfile=/var/log/supervisord.log ; fichier de log principal de supervisord

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; connection pour le client CLI

; liste des processus qu'on veut confier a supervisord
[program:gu-www]
command=/path/to/venv/bin/python /path/to/venv/bin/gunicorn_django -b localhost:8080 --log-file=/path/to/log/gunicorn_gu-www.log --workers=3
directory=/folder/containing/settings/file/
user=www-data
autostart=true
autorestart=true
startsecs=10
redirect_stderr=true
stdout_logfile=/path/to/log/supervisor_gu-www.log

Bien entendu, faites en sortes que l'utilisateur www-data ai accès en écriture aux fichiers de log gunicorn_gu-www.log configuré où le processus échouera lors de son lancement.

ATTENTION: comme indiqué dans le commentaire pour la ligne de configuration inet_http_server il faut absolument faire en sorte que l'adresse ne soit pas accessible à tout le monde! En effet il est possible de redémarrer ou tout simplement stopper les processus par cette interface! Vous pouvez désactiver complètement cette possibilité en supprimant ces deux lignes, il n'y aura alors pas de moyen de contrôler supervisord par une page web.

La commande indiquée pour information lance gunicorn_django avec dans un environnement virtuel (ce que vous devriez faire vous aussi!). Il n'est pas nécessaire d'indiquer le chemin vers le fichier settings.py dans les options de gunicorn_django étant donné que le processus sera lancé directement dans le répertoire le contenant (si vous le configurez correctement avec le paramètre directory comme indiqué ci-dessus).

ATTENTION: il faut absolument que gunicorn_django soit lancé en foreground (en tâche principale, pas en arrière-plan/background/démon/daemon), ce qui est le cas par défaut si vous n'avez pas explicitement dit le contraire dans votre fichier de configuration (ou en paramètre de la commande) de gunicorn_django.

En effet c'est supervisord qui se charge de le faire : si le processus est lancé en arrière-plan, supervisord ne peut pas prendre la main dessus et le contrôler ni le monitorer, et va essayer de le lancer plusieurs fois d'affilée pensant qu'il échoue à chaque fois.

Lancer supervisord et le relancer à chaque reboot

Il suffit pour cela de créer un script de démarrage dans /etc/init.d/ et de le faire se lancer à chaque démarrage.

Dans /etc/init.d/supervisord :

#! /bin/sh
### BEGIN INIT INFO
# Provides:          supervisord
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Example initscript
# Description:       This file should be used to construct scripts to be
#                    placed in /etc/init.d.
### END INIT INFO

# Author: Dan MacKinlay
# Based on instructions by Bertrand Mathieu
# http://zebert.blogspot.com/2009/05/installing-django-solr-varnish-and.html

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
DESC="supervisord"
NAME=supervisord
DAEMON=supervisord
MANAGE=supervisorctl
DAEMON_ARGS=""
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

case "$1" in
  start)
    $DAEMON
        ;;
  stop)
    $MANAGE shutdown
        ;;
  reload|force-reload)
    $MANAGE reload
    ;;
  restart)
    $MANAGE restart
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
        exit 3
        ;;
esac

Ce script contient des commentaires en début de fichier qui permettent de le faire se lancer automatiquement à chaque démarrage :

$ chmod a+x /etc/init.d/supervisord
$ update-rc.d supervisord defaults 99 # le chiffre fourni est la priorité

Cette commande devrait indiquer qu'elle a créé tous les liens symbolique nécessaire pour lancer ce script à chaque démarrage du serveur. La priorité est le chiffre utilisé pour le nom du lien symbolique (S99supervisord, K99supervisord...). Les scripts sont lancés dans l'ordre croissant de ces chiffres : si on veut que supervisord se lance dans les derniers (recommandé, pour que tous les services indispensables soient déjà lancés), il faut un chiffre élevé.

Il ne reste plus qu'à lancer supervisord maintenant et vérifier que notre site est accessible :

$ /etc/init.d/supervisord start

Monitorer et contrôler ses processus

Soit en utilisant le client CLI :

$ supervisorctl

Soit en accédant à la page web dont on a configuré l'adresse dans le paramètre inet_http_server dans le fichier de configuration de supervisord. De là vous pouvez redémarrer vos processus, les arrêter, visualiser le contenu du fichier de log...

Un soucis?

Pensez à regarder dans les fichiers de log indiqués dans les paramètres pour voir si il y a des indications sur le problème
Vérifiez que la commande configuré dans /etc/supervisord.conf se lance correctement manuellement, et que le processus est bien en foreground
Faites un tour sur l'excellente documentation du projet supervisord

Edit du 2010-12-14 : rajout de la priorité de lancement lors de l'appel de la commande update-rc.d

PyCon.fr 2010 : retour sur une conférence organisée par l'AFPY

2010-08-30T08:53:00Z

Cette édition de PyCon.fr était la deuxième à laquelle j'ai assisté. Elle s'est déroulée, comme l'année dernière, à la CyberBase de la Cité des Sciences à la Villette, Paris.

Et comme l'année dernière, j'ai apporté ma maigre contribution à l'organisation sur place, aux côté des super-motivés de l'Association Francophone PYthon (liste non exhaustive : Christophe Combelles, Michael Scherrer, Gaël Pasgrimaud, Jean-Philippe Camguilhem, Olivier Grisel).

Le cadre

Nous avons été encore une fois super bien accueillis par la CyberBase. A disposition, un amphitéatre et une "base technique" (salle équipée de nombreux ordinateurs, idéale pour les mises en applications et les travaux pratiques). Les deux salles ont tout l'équipement nécessaire pour la rétro-projection des présentations, et avaient cette année encore la couverture vidéo de Ubicast.

Les sponsors

Vous trouverez la liste des généreux sponsors sur le site de PyCon.fr 2010. C'est en très grande partie grâce à eux qu'une telle conférence peut être organisée, en restant gratuite, j'en profite donc pour les remercier à nouveau (et les encourager à recommencer l'année prochaine bien évidemment ;).

Nous avons entre autres eu des présentations de plusieurs produits libres et open-source des sponsors Logilab (avec leur solution Cubic Web qui fait tourner le site de pycon.fr) et Itaapy.

Les présentations

Vous trouverez là aussi la liste sur le site de pycon.fr, et je vais lister ici les présentations auxquelles j'ai pu assister et qui m'ont marqué (les autres je les verrais en vidéo, grâce à Ubicast, dès qu'elles seront en ligne) :

plusieurs lightning talks, en particulier sur Pyaler, le GSoC sur distutils 2 (vivement que ça sorte!), pysandbox, restkit
Optimisation d'applications Django de Bruno Renié (mon co-champion "planet" pour django-fr ;) : plein d'astuces pour limiter le nombre de requêtes, utiliser le cache de manière intelligente ...
MongoKit de Nicolas Clairon : comment utiliser une base NoSQL MongoDB facilement et efficacement avec MongoKit
Analyse statistique et classification automatique de texte de Olivier Grisel : ça m'a replongé dans mon mémoire de DEA sur l'apprentissage automatique ;)
l'incontournabl)e Gunicorn de Benoit Chesneau : à mon avis, l'un des plus grands pas en avant pour rendre python (et Django) très facilement déployable
Construire un CMS sur mesure avec Django de Yann Malet : il faut arriver à vendre non pas du forfait (trop risqué pour le développeur, trop cher pour le client, et risque d'effet tunnel), mais des cycles de développement (par exemple de deux semaines, avec review + paiement à chaque cycle, puis décision sur le cycle suivant). Voilà quelque chose qui me plait, mais qui est très difficile à vendre à des clients qui veulent surtout pouvoir chiffrer de manière très précise leur budget
Programmation en Flux de Jonathan Schemoul : présentation de PyF qui permet de traiter de très nombreuses données en limitant la mémoire utilisée (grâce aux "flux"). Très intéressant, et un outil graphique en ligne qui m'a l'air très simple et pratique d'utilisation

Les rencontres

J'ai pu revoir nombre de personnes déjà rencontrées à l'édition de l'année précédent de PyCon.fr, ainsi qu'à Djangocong, personnes que je connaissais déjà auparavant par internet (irc, twitter, mailing lists de l'afpy et de django-fr ...). Revoir "en vrai" des personnes qu'on côtoie très souvent de manière électronique est pour moi toujours une joie et un enrichissement, car l'échange est bien plus facile, et on tisse des liens bien plus étroits autour d'une bière que par internet!

Et comme je l'ai déjà twitté, j'ai par ailleurs été ravi de faire de nouvelles connaissances, que j'espère pouvoir revoir bientôt (un an entre chaque pycon.fr, ça fait long!). Il paraît qu'il devrait y avoir d'ici peu un autre afpyro national organisé, il faudra essayer de rassembler les troupes sur Sophia/Nice à cette occasion! Peut-être une occasion de tester le pastis magique de Jean-Philippe (il m'a promis qu'il ferait un article là-dessus, que je lierai ici ;)

Les bonus

Comme si cela ne suffisait pas, il y a eu quelques bonus très sympathiques :

un écran géant et tactile dans la CyberBase qui affichait en boucle isparade.jp sur le mot clé #pyconfr
j'ai découvert aspirator de Bruno Renié, un news reader fait en django, et qui à l'air vraiment génial... ce gars est vraiment doué, ça en est limite énervant ;). Il travaille aussi sur wombat, un projet de client mail
j'ai revu une bonne partie de mon ex équipe de badminton qui prenait le même avion que moi! (ils étaient aux championnats du monde qui avait lieu ce même week-end sur Paris)
Alexis Métaireau (@ametaireau) nous a parlé de son travail pour le GSoC avec Tarek Ziadé sur distutils 2 : vivement que ce soit dans la stdlib!
Rémi Ubscher (@natim) est Eclaireur lui aussi! Salut Fennec ;)
Benoit Calvez (@_dzen) m'a parlé de fabulator et de vineolia : énorme potentiel (et il a d'autres projets dans les cartons ;)

Conclusion

Vivement la prochaine édition (peut-être sur Pau? ping Jean-Philippe ;) et d'ici là, peut-être une nouvelle édition d'une rencontre Django en france!

Encore un énorme merci aux organisateurs, sponsors, présentateurs, et aux participants, qui font de cet évènement un moment agréable et enrichissant!

djangocong : rencontre Django à Marseille

2010-04-28T08:19:00Z

Comment décrire en un mot cette rencontre Django à Marseille le 24 et 25 Avril :

Excellent !

Après cette entrée en matière fort peu cavalière, permettez-moi de développer en deux points :

Ce que j'ai retenu de ma conférence

Ma présentation portait sur toutes les astuces et raccourcis à la disposition des développeurs web, et s'intitulait Django Pour Les Fainéants.

Les points positifs :

le format "interactif" : faire participer le public le plus possible permet de le garder attentif, éveillé et intéressé
les "bons points" : un autre moyen de captiver l'attention, en récompensant par un bon point (humoristique) les participants
- bon point "glue" : le participant m'a posé une colle, à laquelle je ne sais répondre
- bon point "fainéant" : le participant a proposé une astuce/raccourcis/outil que je ne connaissais pas, ou n'ai pas présenté dans la présentation
- bon point "django pony" : le participant a partagé une bonne pratique django, ou parlé d'une astuce/raccourci/outil que je présentais dans une diapo suivante
- bon point "casse nouilles" : donné à un complice, ou quelqu'un dont on est sûr qu'il le prendra à la rigolade, et qui a fait une remarque sur une typo, une parenthèse manquante...
les diapos "concises" ne contenant pas de phrases, mais des mots clé ou listes de points : permet de garder l'attention du public sur ce que l'on dit, en ne se servant des diapos que comme un support visuel (pour pointer du doigt)

Les points négatifs :

le format "interactif" : difficulté à prévoir le temps de parole pour la présentation. Si il y a beaucoup de participation, le temps de parole prévu empiètera sur le temps consacré (25mn de présentation + 10mn de participation > 30mn). A contrario, si il n'y a pas assez (pas du tout!) de participation, le temps de parole prévu sera trop court (25mn < 30mn).
le format "interactif" et les "bons points" : applicable pour des salles plus grandes, avec un public plus nombreux? Avec 50 personnes, je me demande si on atteignait pas la limite pour ce genre de format...
les diapos "concises" l'étaient peut-être trop : rajouter des photos comme par exemple pour les présentations de Olivier Meunier pour que ce soit plus agréable visuellement (ou comme pour celles de Cyril Baÿ, private joke inside ;)

Dans l'ensemble, je pense que la présentation s'est bien passée, et a été bien reçue d'après les retours que j'en ai eu (merci à tous ceux qui sont venus me complimenter, ça fait chaud au coeur!). N'hésitez pas à me faire vos retours (positifs ET négatifs) dans les commentaires!

Ce que j'ai retenu des autres conférences

Il y a déjà plusieurs comptes rendus très complets sur la toile (liste exhaustive faite par Nicolas Ferrari sur le blog d'AlwaysData), je vais donc essayer de résumer ce que j'ai retenu de chaque présentation :

Django 1.2 : un point de nouveautés, par Nicolas Ferrari : lire les releases notes n'est pas suffisant! pour connaître toutes les excellentes améliorations de la 1.2, il faut soit lire la conf de Nicolas, soit suivre DjangoAdvent ;)
Boîte à outils Django, par Eric Veiras Galisson : de multiples outils pour vraiment être un fainéant (cf ma présentation) et se simplifier la vie !
Cours de géo, par Samuel Adam : c'est pas si compliqué finalement, et LA TERRE N'EST PAS RONDE! présentation très claire sur les outils disponibles et leur puissance
Une authentification pour les contrôler tous, par Olivier Meunier : une "fail story", au moins aussi importante que la "success story" aussi présentée, sur comment adapter l'authentification django à sa sauce
Tester son projet Django, par Bruno Renié : on ne le dit jamais assez, il faut tester ses applications. Non seulement un garde-fou, c'est aussi un gage de la qualité du code final! (et chapeau pour la présentation faite au pied levé pour remplacer un conférencier qui n'a pu venir, et ce moins de trois jours avant la conférence!)
Les dessous d’alwaysdata, par Cyril : on a pas vu beaucoup de dessous, mais on en a appris énormément sur AlwaysData, leur sérieux, leur compétence, et leur boulot au quotidien pour nous simplifier la vie (et nous permettre d'être fainéants!)
Django pour les développeurs Symfony, par Nicolas Perriault : superbe présentation, donnée de main de maître (et hilarante), qui donne un regard nouveau sur ce qu'il est possible de faire avec un langage comme PHP. Au final, Symfony à l'air d'être une bonne alternative à Django quand le client ne veut pas entendre parler d'autre chose que PHP.
Beer over IP, par Bruno Bord : retour d'expérience sur un site reconnu (par moi en tout cas ;) d'utilité publique.
Django et XMPP, par Jean-Michel Armand : quand utiliser XMPP, et surtout quand ne pas l'utiliser! Un retour d'expérience donné par notre cher Jean-Michel préféré!
Gunicorn, Django et WSGI, par Benoît Chesneau : présentation d'un outil que j'utilise en production depuis bientôt un mois sans jamais avoir eu le moindre soucis.
Des lapins et des poneys, quand AMPQ rencontre Django, par Olivier Meunier : explication d'une mise en oeuvre de AMPQ comme moyen de communication entre différents processus, très instructif
Introduction à Pinax, par David Paccoud : boîte à outil pleine d'applications réutilisables qui permet d'arriver à un produit fini avec moins d'efforts et plus rapidement. La question étant, comment faire la part entre un projet "fait main" qu'on maîtrise, et une boîte à outil qu'on ne maîtrise pas forcément. Qu'en est-il de la courbe d'apprentissage?
« Tain cong, Django speaks marseillais, par Stéphane Raimbault : il y a plusieurs formes plurielles dans certains langages (Polonais par exemple), et beaucoup plus de spécificités que je ne m'en doutais! Il va falloir que je reprenne ma copie...
Internationalisation de contenus avec Django, par Benoît Bryon : présentation très claire des limites (et de certaines solutions) de Django pour tout ce qui à trait à la traduction et localisation de sites
CouchDB et Django, l’utilisation de CouchDBKit, par Benoît Chesneau : pas forcément évident à prendre en main, CouchDB est sensé être le choix incontournable quand on tient à ses données (multiples mécanismes comme l'écriture régulière sur le disque pour éviter les pertes de données lors d'un crash)
Les limites de Django, par David Larlet : qui n'a pas été confronté à certaines de ces limites? Un regard réaliste sur ce qu'on ne peut tout simplement pas faire (à l'heure actuelle) avec Django.

Ce que j'ai retenu de l'orga

Un immense merci à David et Jean-Michel, sans qui nous n'aurions tout simplement pas eu cette occasion de se rencontrer entre passionnés de Django (et d'autres! dédicace à Jérémy Lecour), et de voir en chair et en os des personnes (oserai-je dire amis?) qu'on cotoie parfois tous les jours sur internet, certains depuis des années! Merci aussi à Johan Charpentier pour l'impression des TShirts!

J'ai été vraiment impressionné par la ponctualité (malgré les aléas de la restauration et ses délais imprévus), le contenu très fourni et divers de toutes les présentations, le professionnalisme et en même temps l'accessibilité de chacun. Pouvoir discuter et échanger des expériences avec des collègues (comme on dit dans le sud ;) est vraiment enrichissant.

Plus que tout, je tiens encore une fois à remercier Jean-Michel, qui s'est occupé d'une (très) grande partie de la logistique, de nous avoir trouvé les salles, chouchoutés (combien d'aller/retours il a fait pour remplir la cafetière? et de trajets en voiture pour amener/chercher des gens au métro/restau?), et de s'être autant appliqué à nous apporter tout le confort possible.

Vivement la prochaine rencontre!

MySQL, mysqldump et PHP : convertir de latin1 vers utf8

2010-03-08T07:38:00Z

Cet article à pour but de vous éviter, à vous lecteur, de vivre la perte de neurones (et le gain de cheveux blancs) que j'ai subit dernièrement, à investiguer des soucis de charset dans une base de donnée MySQL (et l'affichage sur une page web par le biais de PHP).

Je tiens à préciser que je ne suis pas un expert MySQL, et encore moins un expert en encoding, et certaines définitions ou mots utilisés dans cet article peuvent ne pas être utilisés à bon escient. Le fond et la méthode présentée ont par contre été vérifiés et testés!

Introduction à l'encoding

Je ne parlerais pas ici de ASCII ou Unicode (normes utilisées pour stocker les données), mais du jeu de caractères utilisé pour encoder ces données (et les afficher de manière lisible pour un être humain). Pour commencer, quelques définitions:

encoding = character set = charset : jeu de caractères utilisé pour représenter des données
utf8 = UTF-8 : un encoding qui associe un caractère à chaque "codepoint" Unicode (particularité: tous les caractères hors latin1 sont stockés sur deux octets)
latin1 = latin-1 = ISO-8859-1 : un encoding qui associe un caractère à chaque octet de la table ASCII

Pour résumer, chaque caractère peut être stocké sur le disque en Unicode (ou en ASCII, beaucoup plus limité). Il est ensuite encodé (traduit, représenté) avec un jeu de caractères pour être affichable et lisible par un être humain.

Historiquement, pour les pays occidentaux, l'encodage était fait en latin1 (caractères latins avec ses accentuations). De nos jours, de plus en plus d'applications se tournent vers Unicode et l'encodage en UTF-8 qui permet de représenter l'ensemble des caractères utilisés universellement (il n'est donc pas limité aux caractères latins, mais inclut par exemple les caractères cyrilliques, chinois...).

Charset utilisé par les tables et les champs

Pour consulter l'encodage utilisé par défaut pour une table ou un champ particulier :

mysql> SHOW CREATE TABLE bar;
+-------+-------------------------------+
| Table | Create Table                  |
+-------+-------------------------------+
| bar   | CREATE TABLE `bar` (
  `id` int(11) default NULL,
  `firstname` char(20) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |
+-------+-------------------------------+
1 row in set (0.00 sec)

ATTENTION : les charset définits au niveau de la base de donnée, de la table et du champ sont des "default charset". Il est tout à fait possible d'avoir une table avec un champ dont le contenu est en latin1, puis changer le DEFAULT CHARACTER SET à utf8 pour ce champ. Toutes les données existantes seront toujours en latin1, par contre toutes les nouvelles données entrées en utf8 seront en utf8. On est alors confronté au pire des problèmes : des charsets différents au sein d'une table pour un même champ.

Charset utilisé par le serveur, la database, les tables, les champs, le client, la connexion, les résultats...

Les encodages utilisés par le client, la connexion, le serveur, et l'affichage des résultats sont consultable par la commande suivante:

mysql> SHOW VARIABLES WHERE variable_name like 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Dans cet exemple, le client, la connexion, la database et les résultats sont tous en utf8. Il n'y a que le serveur lui-même qui est en latin1 par défaut. Pour configurer le client, la connexion et les résultats, on peut soit utiliser la commande

mysql> SET NAMES utf8;

Soit configurer les variables décrites dans le paragraphe suivant :

Les variables de configuration

Elles peuvent être définies au niveau du fichier /etc/mysql/my.cnf (peut être situé à un autre endroit selon la distribution):

[mysqld]
default-character-set=utf8
character-set-server=utf8
collation-server=utf8_general_ci # utilisé pour les comparaisons

[mysqldump]
default-character-set=utf8

[mysql]
default-character-set=utf8

L'encoding du terminal: attention au piège!

Quels que soit les charsets (par défaut) que vous avez configurés, il faut savoir que c'est le charset du terminal (si vous êtes en ligne de commande sur mysql par exemple) qui sera utilisé lors d'un UPDATE ou INSERT dans une table.

Ainsi, même si vous avez tout configuré (y compris le SET NAMES) pour être en latin1, lors d'une insertion dans une table, si votre terminal est en utf8 la donnée sera stockée en utf8.

Reportez-vous à cette astuce pour tester le charset (latin1 ou utf8) de votre terminal. Il faut ABSOLUMENT que votre client ai le même encoding que votre terminal pour éviter les `conflits`_ (à partir de la page 21).

Détecter le charset utilisé pour un champ

Commençons par une astuce pour différencier une donnée stockée en utf8 de latin1 :

mysql> select firstname, length(firstname) from bar;
+-----------+-------------------+
| firstname | length(firstname) |
+-----------+-------------------+
| dédé    |                 6 |
+-----------+-------------------+
1 row in set (0.00 sec)

6 octets pour stocker 4 caractères ? C'est de l'utf8! Les accents sont stockés sur deux octets. Si ça avait été du latin1, la longueur de la donnée aurait été de 4 octets.

Mais alors, je peux demander à MySQL de convertir mes données ?

Oui, mais pour savoir où aller, il faut savoir d'où on vient: avant de demander à MySQL de convertir une donnée, il faut connaitre son encodage actuel, et surtout dans quel encodage MySQL croit que ces données sont.

Il faut bien garder en tête que lorsqu'on parle du charset d'une table, d'un champ, d'une base de donnée... on parle du charset par défaut, et donc du charset que le serveur va utiliser pour insérer/retourner des données. Cela n'a aucune incidence sur l'encodage utilisé auparavant pour les données.

charset du serveur égal au charset du client : aucune conversion n'est faite
charset du serveur en latin1, charset du client en utf8 : la donnée va être encodée en utf8 (même si elle l'était déjà => problème de double encoding)
charset du serveur en utf8, charset du client en latin1 : la donnée va être encodée en latin1

Mes données sont stockées en utf8 et MySQL ne le sait pas!

Symptôme: quand on affiche le length d'une donnée avec des caractères accentués, ça donne un nombre d'octets plus grands que le nombre de caractères. La donnée est donc en utf8. Par contre, le serveur, la db, la table, le champ... sont configurés pour être en latin1. Et quand on essaie de faire un SET NAMES utf8, la donnée s'affiche avec des "Ã©" : dans ce cas, c'est une donnée stockée en utf8, mais qui est interprétée comme du latin1 par MySQL, qui va donc l'encoder une seconde fois en utf8 (problème de double encoding).

La solution :

Le serveur pense que les données sont en latin1 et on sait qu'elles sont en utf8 (notre charset final souhaité). Il suffit de

faire un dump de la base dans un fichier en latin1 pour qu'il n'y ai aucune conversion (pas de double encoding)
modifier ce fichier pour y faire disparaitre toute trace de "latin1"
configurer la table, la base de donnée et le serveur pour qu'ils soient en "default charset utf8" (cf le chapitre sur les variables de configuration)
réimporter les données dedans

Mes données sont stockées en latin1 et MySQL le sait, mais je les veux en utf8

Vu que le serveur sait que ses données sont en latin1, il suffit de lui demander de nous les fournir en utf8 :

faire un dump de la base dans un fichier en utf8 pour qu'il y ai une conversion automatique à partir de latin1
modifier ce fichier pour y faire disparaitre toute trace de "latin1"
configurer la table, la base de donnée et le serveur pour qu'ils soient en "default charset utf8" (cf le chapitre sur les variables de configuration)
réimporter les données dedans

Et PHP dans tout ça? Avant ça marchait, maintenant j'ai des � !

Ce cher PHP (hint: passez à Django! c'est bien plus beau!) ne prends pas en compte les configurations mises au niveau du serveur (ou du fichier de configuration) pour son encoding!

Par défaut la commande mysql_connect va toujours utiliser le charset latin1 : vous pouvez en avoir la preuve avec la commande mysql_client_encoding.

PHP va donc vous fournir des données interprétées en latin1 alors qu'elles sont en utf8, d'où les caractères � non valides.

Il suffit alors d'utiliser la commande mysql_set_charset('utf8', $connection) sur la connexion ouverte avec mysql_connect.

Faites bien attention d'avoir définit utf8 pour l'encoding de vos pages HTML soit par une balise meta dans votre entête de page, ou en ayant configuré votre serveur web pour servir les pages en utf8. Un moyen simple de vérifier ça est d'afficher les informations de la page.

Django : Envoyer des emails HTML avec images inline (intégrées)

2010-02-17T10:37:00Z

Voyons comment envoyer des emails multiparties (texte et HTML) avec des images inline (intégrées dans le mail lui-même, et non en pièce jointe), et ceci en utilisant des templates afin de profiter (par exemple) de l'i18n avec gettext, des filtres et tags, de l'utilisation du contexte...

Ce code est un mélange de deux méthodes complémentaires, une sur les mails HTML par Ross Poulton, et l'autre venant d'un djangosnippet par sleytr.

Pour en faciliter l'utilisation et la maintenance, j'ai mis ce petit module django-nice-emails sur bitbucket.

Plutôt que de copier le code ici, je vais plutôt en décrire les grandes étapes:

Utiliser le setting DEFAULT_FROM_EMAIL si l'expéditeur n'est pas fourni
Créer un django.template.Context à partir du dictionnaire fourni (permet de remplacer les {{ var }} dans les templates)
Utiliser le contexte créé pour initialiser le contenu texte, HTML ainsi que le sujet
Transformer le destinataire fourni en liste (si ce n'est pas déjà une liste de destinataires)
Créer un django.core.mail.EmailMultiAlternatives qui est la base de notre email (basé sur le contenu texte)
Rajouter la partie HTML
Rajouter les images en inline si nécéssaire
Envoyer le mai

Rien de compliqué donc dans ce code qui fait moins de 20 lignes "utiles".

Voyons maintenant un exemple d'utilisation avec de la traduction et de l'héritage de templates:

Les templates

On utilise ici la méthode de Ross Poulton qui consiste à ne fournir en paramètre template_name que la base du nom de fichier, sans l'extension. On fournit ensuite au django.template.loader ce template_name avec l'extension .txt et .html, ces templates doivent donc exister tous les deux.

templates/test_email.txt

{% load i18n %}
{% trans "Bonjour" %} {{ nom }},

{% blocktrans %}Ceci est un exemple de "nice-email" que je vous fait parvenir,
à titre d'exemple, et bien que vous vous en fichiez{% endblocktrans %}.

{% trans "Cordialement" %}

Mathieu Agopian

templates/test_email.html

{% extends "base_email.html" %}
{% load i18n %}
{% block email_content %}
<p>{% trans "Bonjour" %} {{ nom }},</p>
<p>
    {% blocktrans %}Ceci est un exemple de "nice-email" que je vous fait parvenir,
    à titre d'exemple, et bien que vous vous en fichiez{% endblocktrans %}.
</p>

<p>{% trans "Cordialement" %}</p>

<p><em>Mathieu Agopian</em></p>
<img src="cid:signature" />
{% endblock email_content %}

templates/base_email.html

<table width="600">
<tr><td><img src="cid:logo" /></td></tr>
<tr><td>
    {% block email_content %}{% endblock email_content %}
</td></tr>
</table>

Le contexte

Un simple dictionnaire python pour chaque tag utilisé dans les templates:

context = {'nom': 'Johnny Biboul'}

Les images

Elles doivent être passées en paramètres dans un tuple de tuples, sous la forme (('/chemin/vers/image.png', 'tagimage'), '/chemin/vers/image2.png', 'tagimage2'), ...). Si les images sont dans le répertoire images du MEDIA_ROOT:

images = (
    (path.join(settings.MEDIA_ROOT, 'images', 'signature.png'), 'signature'),
    (path.join(settings.MEDIA_ROOT, 'image', 'logo.png'), 'logo'))

Dans les templates, on utilisera les images sous la forme <img src='cid:tagimage' />.

Le code

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from os import path
from django.conf import settings
from django.utils.translation import ugettext
from utils.nicemails import send_nice_email


context = {'nom': 'Johnny Biboul'}
images = (
    (path.join(settings.MEDIA_ROOT, 'images', 'signature.png'), 'signature'),
    (path.join(settings.MEDIA_ROOT, 'images', 'logo.png'), 'logo'))
subject = ugettext(u"Test de mail pour %(nom)s") % {'nom': '{{ nom }}'}
send_nice_email(template_name='test_email',
                email_context=context,
                subject=subject,
                recipients='johnny@biboul.com',
                sender='foo bar ',
                images=images)

Conclusion

Il vous suffit de mettre ce code dans une de vos vues pour pouvoir faire de jolis mails de confirmation d'inscription, des newsletters, ou voir même (bouh! c'est mal!) du mass-mailing. Veillez néanmoins à ne pas forcer la dose sur le html, ou les images inlines!

lancer gunicorn avec runit

2010-02-10T11:37:00Z

ATTENTION votre serviteur a fait le test pour vous sur une ubuntu: après avoir installé runit et runit-run, le système ne démarre plus. Pour suivre les étapes de ce billet, il ne faut pas installer runit-run, qui ne doit être installé que lorsque l'on souhaite remplacer totalement le système d'initialisation (et cela demande plus de configuration qu'une simple installation du paquet).

Pour les malheureux qui ont fait les frais de la première version de ce billet (demandant d'installer runit-run), je ne peux que m'excuser platement, et vous fournir la méthode "au secours rescue moi!":

récuperer une installation avec un cd ubuntu

Une fois chrooté sur la partition root, il vous restera à désinstaller le paquet fautif et redémarrer:

$ aptitude purge runit-run

Edité le 2010/02/10 à 20:58

Pour faire suite au précédent billet gunicorn: un server wsgi ultra simple à utiliser et configurer, voici une recette rapide pour lancer automatiquement (et monitorer) gunicorn avec runit.

Pourquoi runit et pas sysvinit, inittab, upstart, ...

Je vous laisse consulter la page benefits sur le site officiel pour vous faire une idée. Pour les personnes ne parlant pas anglais, voici un bref résumé:

Un répertoire par service, contenant un script run
Un environnement d'exécution propre et prédictible pour chaque processus
Service de logging (optionnel) qui sera lancé en même temps que le processus, et en couvrira toute la durée de vie (redémarrages compris!)
Très peu encombrant, efficace... et peut complètement remplacer le système d'initialisation de votre linux

Utiliser runit avec le système d'initialisation actuel

Pour nous faciliter la vie, et ne pas avoir à modifier/importer de nombreux scripts de démarrage pour tous les démons et services déjà installés, nous allons utiliser runit "avec" le système d'initialisation actuel.

Installer runit

$ aptitude install runit

ATTENTION: Si vous installez aussi runit-run, il vous faut absolument configurer votre système (How to replace init), et ce, avant de rebooter (sinon votre système ne démarrera pas, et vous serez contraint à utiliser une méthode de récupération, comme celle présentée en tête de ce billet).

Créer un répertoire pour le service gunicorn et son script de lancement

$ mkdir /etc/sv/gu-monprojet
$ vi /etc/sv/gu-monprojet/run

Et voici le contenu du script run

#!/bin/bash
source /path/to/venv/bin/activate # activer le virtualenv
cd /path/to/django/project
exec gunicorn_django -b localhost:8080 --workers=3

Avec la version de gunicorn utilisée pour l'écriture de cet article, il est nécessaire d'être dans le répertoire du projet django (là ou se situe le fichier settings.py) pour lancer gunicorn_django.

Dans une future version (la modification est dans le trunk à l'heure de l'écriture) il suffira d'indiquer le chemin vers le fichier settings.py comme paramètre à la commande gunicorn_django.

Enfin, ne pas oublier de rajouter les droits d'exécution sur le script qu'on vient de créer:

$ chmod a+x /etc/sv/gu-monprojet

Indiquer à runit qu'il doit lancer le script

Pour celà, un simple lien symbolique, et dans les secondes qui suivent le script sera lancé:

$ ln -s /etc/sv/gu-monprojet /etc/service/

Et c'est tout!

Il suffit maintenant d'en profiter en allant sur http://localhost:8080, en configurant apache pour proxiser les requêtes directement dessus (cf le billet gunicorn: un server wsgi ultra simple à utiliser et configurer), ou encore en utilisant la commande sv pour gérer le service gunicorn:

$ sv status gu-monprojet
$ sv check gu-monprojet
$ sv up gu-monprojet
$ sv down gu-monprojet
$ sv restart gu-monprojet
$ sv hup gu-monprojet

...

gunicorn: un server wsgi ultra simple à utiliser et configurer

2010-02-09T17:08:00Z

Deux billets le même jour, c'est fête!

Voici une recette simple pour installer, configurer et utiliser gunicorn avec apache et django.

Installer gunicorn

Pour installer gunicorn dans son environnement virtuel:

$ pip install -E /path/to/venv install gunicorn

Configurer Apache en proxy

Apache servira les fichiers statiques, et "proxisera" toutes les autres requêtes directement à gunicorn qui sera lancé en local sur le port 8080:

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com

DocumentRoot /path/to/django/project

<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>

# laisser apache servir les fichiers statiques
ProxyPass /robots.txt !
ProxyPass /favicon.ico !
ProxyPass /static/ !

# proxiser toutes les autres requêtes vers gunicorn
ProxyPass / http://localhost:8080/

# robots.txt et favicon.ico sont dans /path/to/django/project/static/
Alias /robots.txt /path/to/django/project/static/robots.txt
Alias /favicon.ico /path/to/django/project/static/favicon.ico

<Directory /path/to/django/project>
    Order deny,allow
    Allow from all
    Options -Indexes
</Directory>
</VirtualHost>

Pour que le tout fonctionne correctement, il faut activer les modules mod_proxy et mod_proxy_html (et en option mod_cache):

$ a2enmod proxy proxy_http cache

Puis de redémarrer le server Apache:

$ /etc/init.d/apache2 restart

Lancer gunicorn

Il suffit de se placer dans le répertoire du projet django (avec le virtualenv activé), puis de taper:

$ gunicorn_django -b localhost:8080 --workers=2

Un ordre d'idée pour le calcul des workers: un de plus que le nombre de CPUs de la machine.

Conclusion

On peut alors se créer un script (a placer dans /etc/init.d) et l'activer pour qu'il se lance automatiquement au démarrage avec la commande update-rc.d (sous Debian), ou utiliser runit (jamais testé, peut-être un futur billet?).

Encore mieux, remplacer Apache par Nginx! (jamais testé non plus, et sûrement un futur billet ;)).

On peut difficilement faire plus simple!

Installer PIL (Python Imaging Library) facilement avec pip

2010-02-09T12:41:00Z

Le fabuleux utilitaire pip de Ian Bicking est un remplacement à easy_install qui fonctionne très bien avec virtualenv (pas étonnant, c'est du même auteur!).

Je laisse le soin au lecteur de consulter la documentation sur ces deux utilitaires très pratiques et indispensables à tout développeur python.

Voici la commande à utiliser pour installer PIL (Python Imaging Library) dans votre environnement virtuel:

$ pip -E /path/to/venv install http://effbot.org/downloads/Imaging-1.1.7.tar.gz

Vous pouvez consulter la liste des versions disponibles en vous rendant sur la page officielle de Python Imaging Library.

ATTENTION: Il faut avoir les sources de python installées et disponibles afin de pouvoir compiler le paquet. Sur debian, il vous suffit de taper

$ aptitude install python-dev

Si vous avez une erreur pip du genre

ImportError: No module named pkg_resources

il vous faut aussi installer python-pkg-resources:

$ aptitude install python-pkg-resources

Obfuscation de l'email alternative et accessible

2009-09-27T12:51:00Z

English translation of this post also available.

Le Problème

Les quatre prérequis pour l'obfuscation d'une adresse mail sont les suivants:

Ne pas pénaliser l'utilisateur: pouvoir cliquer sur le mail
Ne pas pénaliser l'utilisateur: pouvoir copier/coller l'adresse
Ne pas pénaliser l'utilisateur: l'addresse doit rester accessible (en mode texte, sans css et/ou sans js)
Difficilement récupérables par des spambots

L'ordre n'est pas une coïncidence: le but de l'obfuscation est bien entendu d'empêcher les spambots de récuperer l'adresse email, mais celà ne doit en aucun cas pénaliser l'utilisateur du site.

Les différentes méthodes d'obfuscation d'adresse email qui tournent sur la toile, malheureusement, échouent en général au moins sur l'un des 4 points listés.

La Solution

Pour les utilisateurs de webkit avec le javascript désactivé, voir les limitations.

<a href="/contactform.html" id="emailaddress">
    prenom.nom<img src="" alt="@" />example.com
</a>

<script> type="text/javascript">
    mail = new Array("prenom.nom", "example.com").join("@");
    ea = document.getElementById("emailaddress");
    ea.href = "mailto:" + mail;
    ea.innerHTML = mail;
</script>

Et voici le résultat:

prenom.nomexample.com

L’Explication

Si javascript est activé, l’attribut href ainsi que le contenu du lien sont modifiés afin que l’obfuscation soit invisible. Rien de nouveau donc.

Si javascript est désactivé, en utilisant le contenu alternatif d’une image inexistante pour remplacer le « @ », on obtient plusieurs résultats intéressants:

les lecteurs d’écrans liront l’attribut alt pour l’image, l’email étant donc très facilement déchiffrable
l’attribut alt est affiché, rendant l’obfuscation invisible, même en mode texte ou sans css
l’adresse est copiable sans aucun soucis
l’email est toujours clickable, le lien menant sur un formulaire de contact

Un gros avantage d’utiliser un attribut d’un tag html est qu’il contre les spambots qui ne récupèrement que le texte, et non les tags html, afin de ne pas être bloqués par les méthodes d’obfuscation basées sur l’insertion de tags invisibles ou de commentaires dans l’adresse. Ici, supprimer le tag <img> revient à perdre l’information capitale du « @ ».

Les limitations

Il y a deux bugs non résolus dans Webkit à la date de rédaction de cet article:

Les conséquences sont alors visible sur un navigateur utilisant Webkit, et avec le javascript désactivé:

Image manquante sous Webkit

De plus, l’adresse n’est plus copiable, mais le lien (vers le formulaire de contact) reste disponible.

Une solution serait alors d’utiliser une image contenant le symbole « @ », mais celà peut poser des problèmes de style (couleur, famille et taille de la police, anti-aliasing…):

Adresse email avec une image remplaçant le @

Note

Il est possible d’afficher l’attribut alt de l’image sous webkit, en forçant la taille de l’image pour qu’elle soit assez grande:

<img src="" style="height: 60px; vertical-align: top;" alt="@" />

Image assez grande pour afficher l'attribut alt

C’est hideux, mais ça reste lisible, et ça n’impacte que les quelques pourcents d’utilisateurs de webkit qui ont le javascript désactivé.

Conclusion

Voilà donc une nouvelle méthode d’obfuscation d’adresse email, qui devrait être efficace (au moins autant que les autres) contre les spambots, mais qui impacte le moins possible l’utilisateur final. Et surtout, l’adresse est accessible pour les lecteurs d’écrans!

Linux: savoir si le processeur est 32bits ou 64bits

2009-09-24T08:16:00Z

Voici une astuce rapide pour savoir si le processeur d'une machine donnée supporte le 64bits:

Il suffit de vérifier si le flag lm est présent dans les informations de /proc/cpuinfo:

$ cat /proc/cpuinfo | grep lm
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs
bts pni monitor ds_cpl est cid cx16 xtpr lahf_lm

Le flag lm signifie "long mode", comme on peut le voir dans les sources du noyau (include/asm-i386/cpufeature.h):

#define X86_FEATURE_LM          (1*32+29) /* Long Mode (x86-64) */

Vous trouverez une liste de tous les flags sur le blog de Nick Burch (en anglais).

PyCON.fr, excellent!

2009-06-05T06:56:00Z

Et voilà, l'édition 2009 de PyCON.fr, ma toute première conférence sur Python (et ma toute première conférence en tant qu'orateur!) est terminée.

Je tiens à remercier l'AFPY, Association Francophone PYthon, organisatrice de cet évènement. Je remercie aussi tous les membres de l'association, et bénévoles, qui m'ont accueilli aussi chaleureusement!

Je remercie Ubicast qui m'a permis d'avoir ma conférence filmée, streamée et mise à disposition, et qui m'a permit de découvrir et utiliser leur solution vidéo (très ergonomique et facile à utiliser, même pour un novice comme moi).

Je remercie enfin les personnes qui ont assisté à ma présentation, qui ont été réactifs, attentifs et qui ont fait de cette première expérience une réussite!

La présentation en ligne
Les sources sur bitbucket.org
La vidéo (les quatres premières minutes de son manquent)
Toutes les vidéos de PyCON.fr (à l'heure où j'écris ces lignes, toutes les vidéos ne sont pas encore disponibles, mais ça ne saurait tarder!)

PyCon.fr: venez m'y voir!

2009-05-23T07:28:00Z

Toi, oui toi lecteur,

sache qu'il y a une conférence sur Python, entièrement gratuite, qui se tiendra le 30 et 31 mai (autant dire, le week-end prochain) sur Paris, à la Cité des Sciences et de l'Industrie de la Villette.

Tarek Ziadé, le président de l'association AFPY, donne un peu plus de précisions sur cet évènement.

Et enfin un lien vers l'évènement lui même, afin d'y trouver des informations sur le programme: PyCon.fr 2009

J'y donnerai une présentation de 20 minutes sur un billet que j'ai commencé sur ce blog: Les (D)VCS, pourquoi, comment? (le premier article: Le contrôle de version de sources, pourquoi?)

Le contrôle de versions de sources: pourquoi?

2009-03-30T19:07:00Z

Je vais vous raconter l'histoire de Brian. Brian est ingénieur informaticien.

Le crash disque

Brian n'a pas de chance, et il a failli devoir pointer à l'ANPE quand il s'est rendu compte que

Son disque dur avait crashé
Il n'avait pas fait de sauvegarde de son boulot

Heureusement, il a pu récuperer les sources sur le serveur de production, et en moins de deux semaines il a pu réimplémenter les dernières fonctionnalités et corrections de bugs qu'il avait apportées au logiciel.

Le boss indécis

Brian n'a vraiment pas de chance, il a un boss indécis qui vient de lui dire qu'il ne voulait finalement plus de la dernière fonctionnalité en date:

"c'est une très mauvaise idée, commercialement parlant, supprime là au plus vite".

Trois jours plus tard, Brian pense n'avoir oublié d'annuler les modifications dans aucun fichier.

La faute à Murphy

Brian, qui a la poisse, se retrouve à débuguer un morceau de code obscur, et se demande tout à coup qui a bien pu créer ce "code spaghetti".

Serait-ce John, le cousin de l'oncle de sa soeur, qui code comme sa grand-mère?
Ou encore Steven, le surfer blond, qui sort juste de l'école et n'a jamais appris à commenter son code?

Si seulement Brian le savait, il pourrait demander des éclaircissement à l'auteur, et aurait quelqu'un à pointer du doigt à son boss qui vient de sortir son fouet.

Le CPOLD: la fausse solution

Pour reprendre le blog de Roland, le CPOLD à d'innombrables qualités:

pas de format de fichier complexe et susceptible de corruption
pas de conflits
aucun besoin d'un serveur dédié (on peut tout mettre ensemble, prod et dev confondues)
aucune limitation sur la gestion des branches
une rapidité insurpassable
une simplicité de mise en oeuvre et d'apprentissage enfantine
pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles)
des sauvegardes facilitées
etc...

Voici en quoi consiste la mise en place du CPOLD:

$ cp fichier.py fichier.py.old

Et voici un exemple de mise en oeuvre du CPOLD:

foo_dev
    foo.py
    foo.py.old
    foo.py.old.2009_03_29
    foo.py.marche_pas
    foo.py.todelete
    foo.py.OLD.2006_05_12
    foo.py.bak
    foo.py.fonctionalite_bar
    foo.py.bug
    foo.py.save.20081210
    foo.py.check
    foo.py.test

foo_prod
    foo.py

foo_savedev.tgz
foo_save20090329_v2_0.tgz
foo_save20080412_v1_2.tgz
foo_save20060509_v1_0.tgz

Et pour faire bien, voici un extrait du fichier foo.py:

...
def bar(thing): # Added the 10th of june, 2006 -- Steven
    """This function is very usefull!"""
    # Brian: refactored 20080410 for release 1.2
    #if thing == "bar": ### Steven: 11/06/06 fixed typo (was thing = "bar")
    #    return True;
    return (thing == "bar")
...

La fausse bonne idée

Nous avons déjà vu les avantages du CPOLD, maintenant les inconvénients:

Duplication de fichiers
Duplication de code
Réduction dramatique de la lisibilité
Difficulté de grouper des modifications (pour une fonctionnalité par exemple)
Ai-je déjà mentionné la duplication?

Conclusion

Sommes-nous maintenant tous bien d'accord avec Brian pour dire que le contrôle de versions, c'est indispensable? Et que le CPOLD, c'est dépassé?

Dans une prochaine histoire, les enfants, nous verrons avec Brian quels sont les merveilleux outils à notre disposition: les "Version Control System" !

EDIT (05/06/2009): la totalité de cette article (cette première partie ainsi que les deux suivantes, qui ne seront pas publiées sous forme de billet) a été présentée à PyCON.fr. Vous trouverez les liens vers la présentation (en ligne, au format vidéo, et les sources) dans le billet "PyCON.fr: excellent!"

Django, sqlite et mod_wsgi, attention au piège!

2009-03-14T15:34:00Z

Tout d'abord, je tiens à préciser que le problème qui suit n'est pas limité à l'utilisation de django ou de mod_wsgi.

Le contexte

Utilisation de SQLite pour un projet django déployé sur mod_wsgi:

# settings.py
DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = '/opt/mysite/mysite.db'

Et voici les permissions sur le système de fichier:

-rw-rw-rw- 1 ohan ohan 29696 2009-03-14 13:30 mysite.db

Tous les répertoires parents sont eux en 755 (lecture et exécution), ce qui ne devrait donc poser aucun problème, même pour l'utilisateur utilisé par les processus apache/mod_wsgi.

Le problème

Lors de la première tentative d'accès à la base de donnée (par exemple en accédant à l'administration django), une erreur 500 INTERNAL SERVER ERROR est renvoyée, et dans le fichier de log d'apache:

OperationalError: unable to open database file

La solution

Lors de l'accès à un fichier de base de données, SQLite va créer un fichier journal qui lui servira (entre autres) à gérer les accès à cette base. Plus d'informations sur la page expliquant les méthodes de vérouillage: locking in sqlite v3.

Pour créer ce fichier, il faut donc que l'utilisateur puisse écrire dans le répertoire parent.

chmod a+rw /opt/mysite

Ce problème ne devrait se présenter que lors d'un déploiement en environnement de production pour un projet qui utilise SQLite, ou sur un environnement de test si, comme moi, vous préférez tester sur apache directement, et non sur le runserver.

Checklist: différences entre MySQL et les modèles Django

2009-03-02T10:54:00Z

Comme vu dans un précédent billet (MySQL et les modèles Django), il existe des inconsistances entre une base de donnée MySQL et sa représentation par des modèles Django.

Création des tables à partir des modèles Django

Lorsqu'on utilise python manage.py syncdb, les tables créées dans la base de données

N'auront aucun commentaire, que ce soit sur les champs ou les tables, qu'il y ai ou non des help_text et des docstrings
N'auront aucun champ *ENUM*: les champs possédant une liste de choix sont représentés par un *VARCHAR* de longueur égale à la taille du plus long des choix
Les valeurs par défaut indiquées dans les modèles ne sont pas transmises dans les scripts de création des tables
Les *BooleanField* sont représentés par des TINYINT de 1bit
Un DateTimeField avec le paramètre auto_add_now ne sera pas représenté par un TIMESTAMP avec la valeur par défaut CURRENT_TIMESTAMP

Inspection des tables dans Django

Par ailleurs, si la base de donnée existe déjà, et que les modèles sont créés automatiquement par l'utilisation de la commande python manage.py inspectdb, il faudra garder à l'esprit que:

Les commentaires sur les champs et tables ne sont pas traduits en help_text ou docstrings, il faudra donc les dupliquer manuellement
Un champ ENUM sera représenté par un CharField
Les tailles de champ ne sont pas respectées. Par exemple, un Charfield sera avec un max_length de 135 par défaut
Les champs TIMESTAMP avec une valeur par défaut de CURRENT_TIMESTAMP ne seront pas importés en champ avec une valeur par défaut auto_add_now
Les valeurs par défaut ne sont pas importées

Il y a deux derniers points à noter:

Le script d'inspection va importer les champs primary_key pour chaque table, alors qu'ils peuvent être automatiquement générés de manière transparente: un modèle sans primary_key explicite en aura un de manière implicite
Le script d'inspection va créer un modèle pour les tables utilisées pour les relations ManyToMany alors que là aussi, Django peut les générer de manière implicite dans la plupart des cas (lorsque cette table ne contient pas d'information supplémentaire)

Je trouve préférable de laisser la gestion implicite des primary_key et des tables ManyToMany quand c'est possible, dans un soucis de concision et de lisibilité.

Néanmoins, celà introduit une inconsistance entre les modèles et leur représentation dans la base de donnée, inconsistance qui peut porter à confusion.

Plus de cohérence entre les modèles et la base de donnée

Plusieurs possibilités:

créer un script python qui va introspecter les modèles, et automatiquement rajouter les help_text comme commentaires aux champs, et les docstrings comme commentaires aux tables, ou vice-versa
Utiliser des *Custom SQL*
Créer des *Custom fields*
Pour le type ENUM, il existe un *django snippet* qui vise à apporter une meilleure cohérence dans son utilisation

Partagez vos astuces et faites part d'autres incohérences dans les commentaires!

MySQL et les modèles Django

2009-02-24T19:45:00Z

Le problème

D'un côté, une base de donnée MySQL maintenue par MySQLWorkbench. De l'autre, Django et ses modèles.

Entre les deux... pas grand chose.

Les acquis

MySQL et MySQLWorkbench

MySQLWorkbench est un outil excellent pour pouvoir maintenir une base de donnée:

Gestion des commentaires sur les tables et champs
Affichage des relations entre les tables d'une base de données sous forme d'un schéma
Facilité de modification d'une base de donnée en production par l'export de scripts SQL

Django et les modèles

Django, de son côté, nécéssite une représentation de la base de donnée par des modèles. Ces modèles sont des classes codées en Python:

Facilité de suivi des modifications d'un modèle par le biais d'un contrôle de version (Git, Mercurial, SVN ...) accompagné de commentaires pour chaque commit
Facilité de documentation: un paramètre help_text pour chaque champ, un docstring pour chaque modèle
Abstraction de certaines tables et champs générés automatiquement (comme les primary key ou les tables ManyToMany)

Les outils

Comme indiqué plus haut, MySQLWorkbench permet d'exporter des scripts SQL de création et/ou de modification. Il est aussi possible de reverse engineer le dump SQL d'une base de donnée, et ainsi créer toutes les tables dans l'interface graphique, et y visualiser les relations sous forme de schéma.

Django permet l'export de scripts SQL de création, mais aussi l'inspection d'une base de données (par la commande python manage.py inspectdb), ou encore l'exécution de scripts SQL custom à chaque création/modification d'une table (par la commande python manage.py syncdb).

Les méthodes

La méthode basique

... qui casse complètement le principe DRY (Don't Repeat Yourself): maintenir les deux parties en parallèle.

Lorsqu'il faut rajouter une table dans la base, ou y apporter une modification, faire la modification dans MySQLWorkbench, puis répliquer l'ajout/la modification dans les modèles Django.

Pour: Méthode simple, pas de procédure ou méthode à mettre en place.

Contre: Méthode manuelle, sujette à l'erreur humaine (faute de typo, oubli...).

MySQLWorkbench => Django

Maintenance dans l'outil MySQLWorkbench, puis export des scripts de création/modification.
Execution de ce script sur la base de données pour la mettre à jour
Utilisation de inspectdb avec Django pour mettre à jour les modèles

Pour: Méthode automatique, donc pas de risque de typo ou d'oubli

Contre: Méthode très complexe à mettre en place. En effet, inspectdb est loin de créer des modèles fidèles, et il manque de nombreuses informations (un futur billet sera écrit sur ce sujet).

Django => MySQLWorkbench

Ajout ou modification d'un modèle dans Django
Mise à jour de la base de donnée en utilisant python manage.py syncdb (et des scripts custom si nécéssaire)
Utilisation de MySQLWorkbench pour reverse engineer les scripts de création de la base de donnée

Pour: Méthode automatique, donc pas de risque de typo ou d'oubli. De plus, contrairement à la méthode précédente, la représentation des tables est 100% fidèle à la structure de la base de donnée créée par les Django.

Contre: Toutes les informations de commentaires (et d'autres, comme nous le verrons dans un futur billet) sont perdues à chaque modification.

Conclusion

Je n'ai malheureusement pas trouvé à l'heure actuelle de méthode miracle. Il y a des pistes, mais il semble qu'il n'y ai rien de concret pour le moment.

Pour certains cas particuliers, l'une ou l'autre méthode sera préférée:

Création d'une nouvelle table: la méthode Django => MySQLWorkbench sera facile à mettre en place, et il n'y aura rien de perdu vu qu'il n'y a pas d'existant
Modification d'une table par le rajout d'un nouveau champ: l'une des deux méthodes automatique peuvent faire l'affaire
Modification d'un champ d'une table: la méthode manuelle sera en général la plus rapide et la plus simple à mettre en place
Modifications complexes, multiples, perte de donnée possible...: dans ce cas, point de salut, il ne reste que la méthode manuelle, et une grande concentration!

Et vous, quelle est votre méthode?

Apprendre à faire, et faire

2009-02-22T15:03:00Z

Quelle est la meilleure méthode d'apprentissage?

Scénario: "moi, j'apprends"

J'apprends.

Je commence par le tutoriel, que je lis de fond en comble
Je continue par les concepts annexes
J'approfondis quelques sujets qui me paraissent importants, utiles, bons à connaître

Malheureusement, très rapidement

Je prends du retard sur mon projet
Je m'éparpille, je me documente sur des concepts qui ne me serviront peut-être jamais
J'approfondis trop, au détriment d'une vue d'ensemble
Et surtout, je commence à oublier ce que j'avais appris au début, je perds le fil, je me rappelle à peine du tutoriel...

Scénario: "moi, je fais"

Je me lance.

J'essaie de comprendre les concepts de base, peut-être le début du tutoriel
Je me lance, je débute mon projet, et je défriche au fur et à mesure
Quand j'ai besoin d'un nouveau concept, j'épluche rapidemment la documentation, et j'applique mes acquis

Malheureusement, très rapidement

Je passe à côté de concepts très utiles et intéressants
Je ne possède pas assez de bases pour développer mon projet intelligemment
Je ne connaît pas les outils qui me simplifieraient la tâche
Et surtout, je me rends compte que mon projet mériterait un refactoring, alors qu'il débute à peine

Scénario: le juste milieu?

J'essaie de trouver le juste milieu entre "j'apprends" et "je fais".

Je commence par le tutoriel, que je fais
A chaque étape du tutoriel, je met en pratique ce que je viens d'apprendre en faisant quelques modifications/améliorations
Je me fais ensuite (rapidement) une vue d'ensemble des différents concepts et outils disponibles

Ensuite, j'entamme le projet. Le déroulement d'une journée de travail pourrait être :

Je démarre le projet par la partie la plus simple
Dès que j'en ai besoin, j'approfondis un concept/outil nécessaire à l'étape en court du projet
Quand je rencontre un concept/outil adjacent, qui pourrait m'intéresser dans l'avenir, je le marque comme "à lire"
Une fois rentré chez moi, ou avant de commencer le travail le lendemain, je passe un peu de temps à me documenter sur ce que j'ai marqué comme "à lire"

Ma méthode

J'essaie de suivre au mieux le scénario "le juste milieu" : Apprendre chaque jour un peu, et faire. Voici un ordre d'idée du déroulement d'une journée de travail, une fois que le projet est démarré:

Je me réserve une heure le matin, pour me documenter sur des sujets généraux, des outils...
puis j'avance sur le projet, et ne me documente que si nécessaire pour résoudre un problème précis
si je rencontre un sujet que j'aimerais approfondir, j'ouvre un onglet dans mon navigateur pour le lendemain matin

Quelques ordres de grandeur :

Un tutoriel doit prendre quelques heures (au maximum une journée)
Le temps passé à le mettre en pratique en faisant quelques modifications/amélioration ne doit pas dépasser le temps passé à le suivre (donc durée totale "tutoriel + mise en pratique" < 2 journées)
Une fois le projet démarré, se documenter sur un outil/concept doit prendre (en moyenne) moins de 50% du temps de travail (ce ratio doit évaluer en faveur du développement au fur et à mesure de la maîtrise du sujet)

Selon le sujet à apprendre, ces ordres de grandeur varient:

Plus d'apprentissage pour un nouveau langage de programmation (par exemple, Python)
Plus de mise en pratique pour un nouvel outil (par exemple, Mercurial)
Environ 50/50 pour un framework (par exempe, Django)

Et vous?

quelle est votre méthode? Avez-vous des astuces à partager?

Django FileField et ImageField, upload_to et shell python

2009-02-19T19:30:00Z

Le paramètre upload_to des FileField et ImageField

Le champ upload_to permet d'indiquer où sauver un fichier de type django.core.files.File par rapport au MEDIA_ROOT spécifié dans les settings.

Ce champ peut être une chaîne de caractères, ou un callable.

Chaîne de caractères pour upload_to

Pour notre example, prenons le modèle suivant:

class MonModele(models.Model):
    fichier = models.FileField(upload_to="chemin")

Dans ce cas simple, tous les fichiers seronts sauvés dans le répertoire <MEDIA_ROOT>/chemin/.

Si on upload un fichier nommé MonFichier.txt, le chemin complet (sans le MEDIA_ROOT) sera chemin/MonFichier.txt.

Il est par ailleurs possible d'utiliser une syntaxe strftime comme indiqué dans la documentation du module time.

Pour stocker un fichier avec la date et l'heure:

class MonModele(models.Model):
    fichier = models.FileField(upload_to="chemin/%Y%m%d_%H%M%S")

Et le résultat sera chemin/2009-02-19_18:40:03/MonFichier.txt, ce qui n'est pas vraiment ce à quoi on s'attendait.

En effet, cela créera un répertoire par fichier, au lieu de stocker la date et l'heure dans le nom du fichier.

Pour arriver à nos fins, il nous faut utiliser une fonction pour le calcul du chemin de stockage du fichier.

Fonction pour upload_to

Utiliser une fonction pour le calcul du chemin de stockage permet:

de modifier le nom du fichier lui-même, et pas seulement son répertoire de stockage
d'utiliser des informations spécifiques à l'instance du modèle pour lequel on stocke le fichier

Il nous faut par contre respecter les contraintes suivantes:

la fonction aura deux paramètres: self, l'instance, et filename, le nom du fichier uploadé
il n'est plus possible d'utiliser directement la syntaxe strftime

Voici le code qui va stocker un fichier avec la date et l'heure (et prendra la date et l'heure automatiquement ajoutée au champ DateTimeField avec le paramètre auto_add_now):

class MonModele(models.Model):
    date = models.DateTimeField(auto_now_add=True)
    def upload_path(self, filename):
        return 'chemin/%s_%s' % (self.date.strftime("%Y%m%d_%H%M%S"), filename)
    fichier = models.FileField(upload_to=upload_path)

Ce coup-ci, on obtient bien un fichier chemin/2009-02-19_18:40:03_MonFichier.txt, comme prévu.

Tester un modèle avec FileField dans l'interpréteur Python

Pour pouvoir tester un modèle avec un FileField dans un intepréteur Python (python manage.py shell), il y a quelques précautions à prendre, comme commencer par "sauver" le File, comme indiqué sur la page suivante.

En effet, pour que le modèle soit correctement instancié, il faut:

créer une instance du modèle
la sauver (dans notre cas, afin que la date soit automatiquement stockée, et devienne accessible dans upload_path)
ouvrir le fichier à "uploader"
créer un django.core.files.File à partir de ce fichier
sauver ce fichier pour pouvoir ensuite le tester

>>> from mysite.models import *
>>> mm = MonModele()
>>> mm.save()
>>> mm.date
datetime.datetime(2009, 2, 19, 19, 4, 49, 538465)
>>> from django.core.files import File
>>> f = File(open("MonFichier.txt"))
>>> mm.fichier.save(f.name, f, save=False)
>>> mm.fichier
<FieldFile: chemin/20090219_190449_settings.py>

Pour "sauver" le fichier, il faut fournir à la méthode save le nom du fichier (f.name), le fichier lui-même (f), et un paramètre spécifiant si on veut sauvegarder le fichier dans la base de donnée ou pas.

Si nous ne voulions pas accéder à date qui est stockée automatiquement, il aurait été inutile de sauvegarder l'instance de MonModele (mm), et il aurait alors fallut remplacer le code de upload_path de la sorte

def upload_path(self, filename):
    return 'chemin/%s_%s' % (self.date.strftime("%Y%m%d_%H%M%S"), filename)

par

def upload_path(self, filename):
    import time
    return 'chemin/%s_%s' % (time.strftime("%Y%m%d_%H%M%S"), filename)

Django svn et mod_wsgi, attention au piège!

2009-02-17T22:34:00Z

Scénario

Notre cher utilisateur biboul se décide à installer la version de développement de django, que nous appellerons django-trunk, comme indiqué sur la page How To Install Django.

Il lance donc les commandes suivantes:

biboul@laptop:~$ svn co http://code.djangoproject.com/svn/django/trunk/ django-trunk
biboul@laptop:~$ ln -s `pwd`/django-trunk/django /usr/lib/python2.5/site-packages/django
biboul@laptop:~$ ln -s `pwd`/django-trunk/django/bin/django-admin.py /usr/local/bin

Il a bien entendu

configuré son serveur apache pour utiliser le module WSGI
testé avec le script wsgi "hello world" que la configuration était bonne
modifié le script wsgi de manière à utiliser son application django mysite

Le problème

Lors de la première requête à son application mysite, une belle "500 Internal Server Error" s'affiche, avec les messages d'erreurs suivants dans le fichier /var/log/apache2/error_log:

...  mod_wsgi (pid=5803): Target WSGI script '/opt/tcs/tcs.wsgi' cannot be loaded as Python module.
...  mod_wsgi (pid=5803): Exception occurred processing WSGI script '/opt/tcs/tcs.wsgi'.
...  Traceback (most recent call last):
...       File "/opt/tcs/tcs.wsgi", line 6, in <module>
...           import django.core.handlers.wsgi
...  ImportError: No module named django.core.handlers.wsgi

Mais pourquoi donc, alors qu'un import django.core.handlers.wsgi fonctionne correctement, que ce soit dans l'interpréteur ou dans le shell django?

La réponse

Tout simplement parce que le répertoire django-trunk (dont notre cher utilisateur biboul a fait un lien symbolique dans le répertoire*site-packages*) n'est pas accessible à un utilisateur différent, si il n'est pas dans le même group.

Or, par défaut et sur la plupart des distributions Linux, les processus apache sont lancé avec un utilisateur limité (www-data, www ou encore apache).

La solution

Un simple chmod 755 des répertoires parents au répertoire django-trunk est suffisant pour régler ce problème.

Une autre solution, plus propre et sécurisée, serait de placer le répertoire django-trunk dans le répertoire /opt, et de modifier les liens symboliques pour utiliser ce nouvel emplacement.

30 ans, et toutes mes dents

2009-02-15T23:06:00Z

30 ans aujourd'hui.

Il reste encore une petite heure dans cette première journée de mes 30 ans. Et je commence un blog.

Je jette dans ce tout premier billet les motivations pour ce blog (qui restent pour l'heure très vagues):

Avoir un aide-mémoire
Structurer mes pensées et divagations
Ajouter ma pierre à l'édifice

Quelques règles pour les futurs billets:

Travailler sur la concision et la clarté
Une écriture claire, simple et directe
Pas de billets inutiles

A bientôt pour la suite.