Miximum
Le blog d'un ingénieur Web freelance.
Tripodocus est un site entièrement réalisé en Django sur lequel je publie quelques photos. La plupart des images sont publiques, d'autres sont privées et uniquement accessibles aux personnes autorisées. Django génère aussi des thumbnails pour chaque photo.
Django est un excellentissime framework web. Tellement excellentissime que c'est un outil que j'emploie depuis quelques années avec toujours autant de plaisir.
Ces quelques années m'ont amené à considérer certaines façons de faire plutôt que d'autre, et à compiler une liste de bonnes pratiques qui me paraissent positives dans la majorité des cas.
Ces bonnes pratiques ont différents objectifs, qui finissent plus ou moins par se rejoindre :
Configurer un projet Django pour servir un site en https, c'est facile et c'est pas cher. Si si, je vous jure !
Imaginez un combat homérique entre les forces du bien et du mal, luttant pour la domination du monde. Dans le camp des forces du mal : la procrastination, Internet Explorer et les cycles en V ; dans le camp des forces du bien : Python, le café et les tests automatisés.
Tout le monde aujourd'hui est d'accord pour dire qu'écrire des tests est probablement la tâche la plus efficace quand il s'agit de garantir un code robuste et maintenable. (Enfin, presque tout le monde ; ceux qui dénigrent les tests sont en général ceux qui sont trop flemmards pour en écrire.)
À ce titre, Django se montre exemplaire, et la documentation relative aux tests est aussi complète que détaillée. Seulement voilà, quiconque a déjà travaillé sur un projet Django pendant plus de quelques semaines sait que de nombreuses questions sont laissées de côté. Et notre développeur / testeur est réduit à parcourir les bas-fonds du web pour trouver réponse à ses questions.
Sans plus tarder, voici quelques réponses à ces questions.
J'ai parlé de Documentation Driven Development l'autre jour. Cela dit, si tout le monde est d'accord pour dire qu'une bonne doc est important, personne ne nous dit jamais ce qu'est vraiment une « bonne » doc.
Du coup, on se retrouve souvent avec des docs pourries et donc des logiciels difficiles / pénibles à utiliser.
Voyons donc comment documenter correctement une application Django (ou n'importe quel projet Python, hein, c'est juste pour l'exemple concret et mon référencement).
Django, c'est bien. Par contre, déployer un projet Django en production, ce n'est pas toujours évident, surtout que la doc n'est pas forcément toujours très à jour à ce sujet.
La dernière fois que j'ai dû effectuer un déploiement bien propre en production, j'ai un peu regretté de ne pas avoir sous la main un beau tuto bien récent, bête et méchant. Comme j'ai dû rédiger la doc complète de l'opération, en voici la version française.
Au menu : du Nginx en frontal et reverse proxy vers Gunicorn qui sert notre projet tournant dans un virtualenv (foutaises !). On y va ?!
Bien que Django constitue un outil de travail de fort bonne facture, je tombe de plus en plus souvent sur des projets avec des besoins de CMS. Or, je veux bien être pragmatique, mais ça me fait un peu mal quand je me retrouve à conseiller à un client l'installation d'un Wordpress ou d'un Drupal, même si c'est l'outil le plus approprié sur le moment.
J'ai fini par fouiner pour voir s'il n'existait pas de bons CMS en Python. Les principaux proposés par la communauté sont Django-cms, FeinCMS et Mezzanine. Résolu à tester les trois, j'entrepris de les installer rapidement pour jouer un peu avec. Las, la documentation des deux premiers semble lacunaires, car dés les premières commandes, je fut confronté à des erreurs non référencées, et après plus d'une demi-heure passée sur Stackoverflow, je laissais tomber pour ne pas perdre trop de temps.
Finalement, j'ai fini par installer Mezzanine, sur recommandation de @n1k0, et il a bien voulu fonctionner docilement sans mettre ma patience à l'épreuve (Mezzanine, pas @n1k0). C'est donc ce projet que j'ai testé plus en profondeur.
L'autre jour, j'étais tranquillement assis dans mon fauteuil, sirotant mon café et dépilant une à une les stories de mon backlog avec la régularité d'un opérateur de train nippon lorsque sans grier « gare ! » mon instinct de développeur affuté par des années de labeur se mit à clignoter.
« Cette fonctionnalité, me murmura l'instinct susmentionné, ferait un candidat parfait à l'écriture d'une application dédiée. »
Il y a un poil moins de deux ans, j'écrivais ici-même un billet dans lequel j'expliquais pourquoi j'avais décidé de laisser tomber Symfony premier du nom pour voguer vers de plus vertes terres pythonesques. La bataille qui fit rage dans les commentaires ferait passer la plus épique scène du Seigneur des Anneaux pour une querelle dans un jardin d'enfants, et ce billet reste à ce jour l'un des plus vus sur Miximum. Le temps a passé, et j'ai pensé qu'il pourrait être intéressant de proposer un petit retour d'expérience sur cette migration. Alors, Python, Django, c'est bien, ou c'est très bien ?
Dans la plupart des projets Web, contacter les utilisateurs par email est largement suffisant. Mais il arrive que l'on souhaite utiliser d'autres modes d'interaction, tels que le sms. Comparé au mail, le sms présente certains avantages :
Évidemment, tout le monde est bien conscient que c'est un média de communication qui présente également des inconvéniants :
Dans ce rapide tutoriel, nous allons voir quels sont les moyens à notre disposition pour envoyer des sms depuis un projet Django.
Dans le cadre de la création de DontForgetGrandma.com, un programmeur d'alertes par sms, j'ai testé l'intégration de formulaires de paiement avec Paymill.
Il y a quelques jours, alors que je bossais sur mon pet project du moment, je me suis surpris à penser « tiens, ça serait bien si cette fonctionnalité devenait une application Django réutilisable ». La fonctionnalité en question ne nécessitant pas plus de quelques lignes, je me suis dit que ce serait rapidement torché.
Le fait que je me retrouve 10 jours plus tard et deux applications supplémentaires me prouve encore une fois que je suis vraiment mauvais avec les estimations. Et on s'étonne que je ne travaille pas au forfait …
Quoi qu'il en soit, pour la dernière app, j'ai décidé de tester l'approche Documentation Driven Development. Retours d'expérience.
Je l'ai déjà écrit plus tôt : Mezzanine est un chouette projet. Toujours dans l'optique de jouer avec ce bel outil, je me suis assigné la tâche d'afficher une joli carte quelque part. Comme ça, juste parce que. Voyons comment faire.
À peu près tout ce que je sais sur la cartographie (c'est à dire le strict minimum, je l'avoue), je l'ai appris durant les rencontres Django 2012, lors de l'excellente introduction à ce noble art par Mathieu Leplatre. De quoi avons nous besoin pour afficher une carte interactive, sans toutefois passer par l'hégémonique Gogole ? Simple :
J'aime Postgresql, le moteur de base de données le plus ennuyeux au monde. Une technologie tellement fiable et éprouvée que tous les cool kids essayent absolument de la remplacer par autre chose. Pourtant, Postgres offre tellement d'avantages que tout projet qui ne s'appuie pas dessus me semble de facto suspect. Aujourd'hui, nous allons passer en revue l'un des aspects offert par Postsresql : ses fonctionnalités de recherche.