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 ?
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.
Comment écrire une suite de tests maintenable ?
Comment tester des fonctionnalités qui utilisent javascript intensément ?
Comment tester des fonctionnalités qui font appel à des web services et sont fortement couplés ?
Comment être certain que les tests qui tournent sur ma machine fonctionneront aussi sur la prod ?
Sans plus tarder, voici quelques réponses à ces questions.
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).
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. »
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 ?!
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 :
Après avoir étudié les concepts de base du machine learning, nous allons nous attaquer au deep learning en apprenant comment fonctionnent les réseaux neuronaux.
Javascript est un langage qui dispose de sa propre logique un peu tordue. Sa syntaxe ressemble vaguement à celles d'autres langages, mais on obtient parfois des résultats suprenants. Et puis ces erreurs incompréhensibles « this is undefined », « undefined is not a function », etc. Mais pas de paniques, suivez ce tutoriel pour bien comprendre Javascript.
Tout le monde a entendu parler de Docker, une technologie « superstar » de ces
dernières années. Le type de technologie tellement hype qu'on a envie de s'en
servir, même quand on ne comprends pas bien ce que ça fait et que ça n'est pas
vraiment adapté à ses besoins. Et LXC, vous connaissez ?
Dans ce billet assez technique, nous allons étudier un outil mathématique poétiquement intitulé les « courbes elliptiques ». Même si vous ne savez pas ce que sont les courbes elliptiques, vous en avez utilisé sans le savoir, car elles constituent l'un des fondements de la cryptographie moderne. Accrochez-vous.
Miximum
