jsUnit

Kent Beck dit que lorsqu’il découvre un nouveau langage de programmation, il commence par écrire une suite de tests unitaires. Ma foi, pourquoi pas se lancer dans les tests unitaires en écrivant une telle suite qui s’auto-testerait ?

J’ai choisi le JavaScript, car je commence à comprendre les intérêts de ce langage, basé sur les prototypes et non pas sur un système d’héritage et de dérivation comme les langages objets qu’on connait généralement. J’ai aussi choisi le JavaScript car il n’a besoin que d’un navigateur, et de rien d’autre.

Ce fut plutôt sympa à faire, car je souhaitais que le script JS soit suffisant à lui-même et qu’il ne requière pas de fichier CSS externe. J’ai donc dû chercher comment injecter correctement du CSS dans un document HTML via JS, et qui soit compatible avec Gecko, IE et Webkit.

La solution est dans le code, et le résultat est disponible sur github : http://www.github.com/ysbaddaden/jsunit/

Résolution 2009

Ne prenons pas de résolution impossible à tenir. C’est idiot et ça fait perdre du temps. Me coucher tôt, me lever tôt, prendre un petit déjeuner en écoutant de la musique et lisant mes blogs et webcomics favoris ; au lieu de courir chopper mon train (ou prendre le train suivant) ça serait pas mal. Mais bon.

Soyons plus réaliste : et si j’essayais de me concentrer et d’organiser mon temps ? On peut organiser sa TODO, alors pourquoi ne pas m’organiser un peu dans mes activités ?

Ça ne paraît pas comme ça, mais c’est très dur de s’organiser. Je ne souhaite pas réguler ma vie, juste poser le temps (et non pas le trouver) de faire certaines choses, que je ne fait pas naturellement.

Par exemple je travaille à 80%. C’est un choix que j’ai fait lorsque j’ai commencé à travailler. Je n’ai pas besoin d’un salaire à temps complet et je souhaitais conserver une partie de mon temps pour mes projets, notamment pour Webcomics.fr. Le problème c’est qu’il est dès lors facile de se lever à 11h, de prendre son petit déjeuner en jouant à la Wii et se rendre compte qu’il est déjà 18h lorsque sa copine rentre. Il est beaucoup plus dur de se lever à 9h et de travailler une bonne partie de la journée.

Le problème c’est que dès lors je vais commencer à culpabiliser : j’ai rien foutu, c’est pas bien, j’ai encore tout ça à faire, etc. Ça me fout le bourdon, alors j’essaye de bosser les soir de semaine, mais c’est encore pire : on ne peut pas bosser sérieusement le soir, après une journée de boulot. Résultat le lundi d’après, où je suis censé être en pleine forme pour travailler, ben… hum, voilà quoi.

Alors plutôt que de continuer à faire n’importe quoi, je vais essayer de mieux m’organiser. De vraiment bosser le lundi sur Webcomics.fr, et de me détendre le soir. Je ne parle pas de glander, mais d’écrire des articles pour ce blog, lire des livres, jouer à des jeux vraiment bien (Phoenix Wright !) et zapper ce qui ne vaut pas tripette. Le tout en écoutant de la musique et en gardant la télévision éteinte.

Bref rien d’insurmontable en soi : bosser quatre jours par semaine à mon boulot ; bosser une journée par semaine sur Webcomics.fr ; utiliser mes soirées pour moi et ma famille ; et mes week-ends pour voir mes amis et pour mes projets personnels.

Ça me paraît bien.

Utiliser sa liste TODO

L’une des premières choses qui m’a marqué dans la lecture de Test Driven Development de Kent Beck, c’est sa manière de gérer sa liste de choses à faire lorsqu’il programme.

Attaquant un problème, il le grasse dans sa liste, de manière à mettre en avant ce sur quoi il est en train de travailler, ce qui est pratique pour savoir ce sur quoi on était en train de travailler, quand on revient le lundi au boulot. Voire après une simple pause café : un coup d’œil et on est repartit ! Pas besoin de réfléchir et pas de distractions (par ex. aller voir ses emails).

Par la suite, travaillant sur quelque chose il pense à divers problèmes ou choses à faire en rapport avec ce qu’il est en train de programmer. Systématiquement il note sa réflexion dans sa liste TODO, puis retourne à ce qu’il était en train de faire. Ayant noté sa réflexion, il peut l’oublier et y repenser plus tard, lorsqu’il consultera à nouveau sa liste. En attendant il reste à ce qu’il fait et ne se disperse pas.

Ceci est un principe de base des tests unitaires : décomposer les choses au plus simple, et les implémenter une par une. Lorsqu’on travaille sur une chose, on reste concentré dessus et on ne se disperse pas à vouloir régler tous les problèmes en même temps.

C’est pour cela, si j’ai bien suivi, qu’on parle de « tests unitaires » (unit tests en anglais) : on implémente les choses une à une. À vouloir tout faire en même temps on va tout mélanger. Par exemple un bon repas est composé d’une entrée, d’un plat et d’un dessert. On peut tout mélanger, mais je ne pense pas que ce soit une bonne idée. Imaginez donc un gâteau au chocolat avec une soupe de poisson. Pas top, hein ?

Lire la suite « Utiliser sa liste TODO »

À propos des Frameworks

Je pratique les frameworks depuis quelques années, car je trouve les principes type Domain, MVC, etc. extrèmement pratiques. Je n’arrive cependant pas à en trouver un qui me plaise. Je fais régulièrement le tour des frameworks PHP principaux, mais je trouve généralement qu’ils sont beaucoup trop compliqués, et qu’ils ne résolvent pas mes problèmes. Le principal étant de me simplifier au maximum la vie sur les tâches répétitives et d’être opérant immédiatement, sans avoir à coder 5 classes juste pour un modèle.

Je n’ai par exemple toujours pas compris comment créer un modèle avec le Zend Framework. À part qu’il faut apparemment générer 3 classes, juste pour un modèle.

J’ai donc fini par me coder un framework perso, que j’ai réécrit deux fois. Mais :

  • il n’y a aucun test unitaire ;
  • je suis le seul à bosser dessus ;
  • je n’ai donc aucun retours d’utilisateurs ou d’autres programmeurs ;
  • la plupart des idées de la dernière version viennent directement de Rails.

Pourquoi m’embêter à coder en PHP ce qui existe déjà pour Ruby ? En plus, Rails est plein d’idées que je trouve excellentes, qui me plaisent et que je copie sans vergogne. Quel intérêt alors de maintenir un tel framework ? Ça me semble idiot, surtout depuis que j’ai lu Practices of an Agile Developer.

Certes, développer un bon framework, simple, accessible et reprenant les bonnées idées de Rails mais basé sur PHP et non pas Ruby est intéressant. PHP est plus courant chez les hébergeurs par exemple, donc plus facile à déployer. Cependant coder tout seul dans son coin, et voir ses projets (Webcomics.fr par ex.) traîner du pied parce qu’il faut maintenir et faire évoluer son framework… c’est juste idiot.

Je ne rejette pas l’idée de coder un framework PHP5 tel que définit au paragraphe précédent, mais pas tout seul, et surtout : développé Test Driven, c’est-à-dire que les tests doivent conduire la programmation (et pas l’inverse). Si ça vous êtes intéresse et que vous maîtrisez le modèle objet PHP5, contactez-moi, car ça m’intéresse !

Pour le moment j’étudie Ruby, Rails, et j’apprends des trucs. Je ne sais pas ce qu’il en ressortira : un framework calqué sur Rails mais pour PHP5 ? Ou peut-être finirai-je par switcher et passer à Ruby ?

Bienvenue au monde !

Développeur Web, je lis de temps en temps des bouquins, et quotidiennement tout un tas de blogs. J’ai récemment lu quelques livres : Practices of an Agile Developer et Test Driven Development.

Practices of an Agile Developer pousse à être plus réaliste. Il ne m’a pas fondamentalement remis en cause, mais il m’a remis les points sur « i », notamment sur «comment ne pas perdre son temps ? » En gros : ne pas se prendre la tête à programmer ses propres outils (eg: un framework) lorsque d’autres l’ont déjà fait, et bien fait. Autant passer tout ce temps économisé à se concentrer sur ses projets.

Test Driven Development est quant-à lui un livre à lire absolument. Je connaissais un peu les xUnit, mais sans vraiment en comprendre l’intérêt ni la manière de le mettre en œuvre et ne m’y suis jamais vraiment intéressé. L’auteur, Kent Beck, m’a fait comprendre pourquoi les tests unitaires sont indispensable à tout projet et toute l’importance de programmer d’abord les tests. Le développement d’une application se simplifie et l’évolution d’une fonction ou d’une classe ne devient plus une source d’angoisse, mais un moteur. Il suffit de lancer ses tests automatiques pour vérifier si quelque chose a été cassé, auquel cas on répare, sinon tout continuera à marcher comme avant. C’est tout bête, mais c’est génial.

Malheureusement ces livres ne sont pas disponibles en français — tout comme beaucoup de ressources sur la programmation — pourtant indispensables. Tout le monde n’a pas un niveau suffisant en anglais, ni la motivation pour se farcir un livre de programmation en anglais dans le texte.

Je me suis donc décidé à commencer un blog, en français. Pour moi et les gens qui ne parlent pas suffisamment anglais pour lire Test Driven Development et Rails for PHP Developers par exemple.

Je parlerai bien entendu aussi de choses diverses concernant la programmation Web, tel JavaScript et Internet Explorer par exemple, ou encore les frameworks, etc.

Propulsé par WordPress.com.

Retour en haut ↑