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.
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.
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 existe de plus en plus d'outils pour bootstraper rapidement la création de petits sites web, minimaux mais fonctionnels. Ainsi, le développeur aspirant entrepreneur pourra tester son idée et créer un service sympathique et pas trop moche en quelques heures, et passer de l'idée au MVP en quelques jours à peine. Le seul obstacle, la seule difficulté technique difficilement surmontable reste encore la mise en place du paiement.
Ça fait quelques temps (depuis la sortie de firefox 3.5, en fait) que j'avais envie de jouer avec quelques sélecteurs css issus de la version 3 de la norme. En fait, nous allons nous amuser avec quelques pseudos-classes. Pour les cancres, les pseudos-classes sont un mécanisme de css qui permet de sélectionner des éléments selon des critères qui ne sont pas explicitements contenus dans de document.
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 :
J'utilise Git quotidiennement depuis plus de dix ans. Bien que Git soit un outil extrêmement puissant, il n'est pas très intuitif. Sans bien comprendre les mécanismes internes du logiciel, on se retrouve vite coincé. Par conséquent, voici un tutoriel ulta-détaillé pour bien appréhender les principes et les principales commandes de Git.
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.
J'utilise git au quotidien depuis plus de 10 ans maintenent et git-rebase est tout simplement l'une de mes fonctionnalités préférée. Pourtant, lorsque je donne des formations sur Git, je m'aperçois que cette commande est souvent mal comprise et mal utilisée. Nous allons donc étudier en détail la commande git-rebase : À quoi elle sert vraiment, et comment bien l'utiliser.
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 ?
Miximum
