GTD

22 12 2007

Comme je l’ai déjà dit, je suis un feignant. Et en tant que feignant, j’ai tendance à toujours remettre au lendemain ce que je devrais faire le jour même … la résultante de tout ceci étant une masse de travail énorme pour faire tout ce que j’avais dit que je ferais et que j’ai (presque) oublier de faire …

Toutefois, j’essaie de me battre contre cette tendance et de trouver de nouveaux moyens de m’améliorer et de livrer en temps et en heure le meilleur travail dont je suis capable …

Afin de ne pas oublier ce que j’ai à faire, et d’arriver à le faire, je me suis tourné vers les méthodologies issues de GTD (Getting Things Done — Faire les Choses). J’ai de suite trouvé le concept clair et cohérent: l’idée générale est de vider l’esprit de toutes les choses dont on a besoin de se souvenir (acheter le pain, écrire des rapports de réunions …etc…) en les écrivant, et en revoyant de façon réguliére vos listes de choses à faire (en fonction du contexte dans lequel vous vous trouvez: à la maison, devant l’ordinateur …).
En tant que geek, ma première réaction pour noter mes listes de choses à faire a été d’utiliser un ordinateur. Ce qui a conduit au dévelopement de toutes une tripotée d’outils (de la simple liste “todo” en ligne de commande avec publication de flux RSS, jusqu’à une liste “todo” basée sur des contextes, que j’updatais au moyen d’une combinaison de touches en utilisant un mélange de Launchy et de Snarl pour la notification visuelle), puis à l’utilisation de plusieurs outils écrits par d’autres (ThinkingRock, GTDMonkey, un plugin pour Lotus Notes, …).

Toutefois, aucun d’eux ne m’a pleinement satisfait … Je commençais à les utiliser, puis après un certains temps j’arrêtais de maintenir mes listes …

J’ai maintenant trouvé mon outil “parfait” pour cette tâche, ou plutôt devrais-je dire mes outils parfaits: un cahier, un stylo noir et un stylo rouge.

Je passe beaucoup de temps en réunion, et il est plus naturel pour moi, plus simple, de prendre des notes “manuellement”, que d’utiliser mon ordinateur portable pour cela (il est difficile d’ajouter rapidement des croquis avec son ordinateur par exemple). J’ai donc developé une méthode simple pour garder trace de toutes les choses que je dois faire ou déleguer.

Dans la marge gauche de mon cahier, je dessine, en rouge, un ‘[ ]’ pour toutes les tâches que je dois faire moi-même, et j’écris à droite de cette marque, la tâche, en noir, et de façon détaillée. Si je dois déleguer cette tache ou qu’elle se réfère à quelqu’un d’autre, je trace alors un ‘( )’ au lieu des crochets, et j’indique en rouge le nom de la personne concernée.
GTD

Chaque fois que l’une de ces taches est soit terminée, soit déleguée, je coche l’espace entre les crochets ou les parentheses.

Le fait d’utiliser 2 couleurs differentes, me permet de tourner rapidement les pages de mon cahier pour vérifier ce qu’il me reste à faire ou ce que j’ai déjà fait.

Si je dois ajouter une tache qui n’est pas directement reliée à la reunion à laquelle j’assiste (une idée sans rapport arrivant d’un coup), j’utilise la même technique mais en utilisant la marge du haut de ma page.

Cette technique peut paraitre simpliste ou vieille école, mais bon, au moins elle marche pour moi.




J’y serais …

18 11 2007

Paris On Rails




Les bons outils …

9 08 2007

Vous savez que les 10 dernières minutes ont été productives quand vous passez de:

Total time: 15.5901584625244Average time: 3.11803169250488

à

Total time: 3.72735238075256Average time: 0.745470476150513

La raison de cette subite amélioration des performances ? Rien de bien compliqué: juste le fait que la dernière mouture de ruby-prof facilite grandement l’analyse des performances d’une requête donée .. et par là-même simplifie le travail de celui qui essaie d’optimiser un tant soit peu une application web déjà gourmande.

Ajoutez à cela un bon exemple d’utilisation de la part de l’auteur même, et vous avez une amélioration des performances assez impressionante qui somme toute se résume au changement de 2 ou 3 lignes de code. Le plus amusant étant que la cause de ces performances pitoyables était exactement la même que celle expliquée dans l’article: l’utilisation abusive de ActiveRecord#attributes au sein d’une méthode appelée lors de chaque accès aux champs d’un objet :

%self     total     self     wait    child    calls  name
 55.20     28.28    27.35     0.00     0.93    82447  Kernel#clone

Comme quoi, quand on a les bons outils …




Manage It !

18 07 2007

Ca y est ! Je l’ai reçu !

Suite à ma revue de Manage It ! (qui d’ailleurs s’appelait, au moment de la relecture, “Successful Project Management”), les PragProg m’ont envoyé ma version papier de l’ouvrage :) Le timing est plus que bon, puisque je vais avoir le temps de le re-lire pendant les vacances.

Ce livre est tout simplement génial. Facile à lire, et comme toujours bourré de bon sens (le bon sens qui fait qu’à la lecture de certains passages on se dit: “Bien sûr ! Mais pourquoi je ne fais pas déjà ça ??!” .. bref un livre dans la digne lignée de ceux deja edités par les PragProgs.

L’auteur s’attache à décrire les différentes étapes de la vie d’un projet (Commencer un projet, Plannifier le projet, Adapter le cycle de vie en fonction du projet, Estimer la charge de travail ..etc.) de façon claire, simple et pragmatique, sans se lier à un outil particulier, avec seulement le bon sens qui caracterise les livres des PragProgs … bref un must-read pour tous les (futurs) project managers.




BDD

9 05 2007

BDD - Behaviour Driven Development … En français, sans doute quelque chose comme “Développement piloté par le comportement”.

J’étais un fan de Test Driven Development (TDD pour les intimes) … que ce soit dans des languages qui s’y prêtent bien (Ruby, Perl, …) ou pas aussi bien que ça de prime abord (C pour ne pas le nommer)… Un des points fort de cette technique, à mon avis, réside dans le fait qu’elle permet de se placer du point de vue du futur utilisateur de l’API/classe que l’on est en train de développer … et d’avoir toute de suite un retour sur sa facilité d’utilisation, son ergonomie …

BDD n’est en ce sens pas tres éloigné de TDD … avec un coté plus “positif”. En effet, en TDD, on teste son code, avec toute la connotation négative que cela peut avoir ;), alors qu’en BDD on spécifie la façon dont va se comporter le code, et on vérifie qu’il le fait.

Cela peut-être très agréable à lire/écrire si le framework/librairie utilisé se plie bien à cela. Par exemple, en Ruby, et en utilisant RSpec:

Code (ruby)

context "A username with a strange-case fullname" do
  setup do
    @username = UserName.new( "joobarbaz", "jean-Christophe oobar BAZ" )
  end 

  specify "should have correctly capitalized firstname" do
    @username.firstname.should == "Jean-Christophe"
  end

  specify "should have correctly capitalized lastname" do
    @username.lastname.should == "Oobar Baz"
  end
end

Le DSL utilisé permet de spécifier ce que doivent faire les méthodes de la classe et de pouvoir le tester. Si l’on exécute le bout de code précédent:

$> spec -fs username-spec.rb
A username with a strange-case fullname
- should have correctly capitalized firstname
- should have correctly capitalized lastname
$>

.. on en arrive à un affichage de la specification pendant que celle-ci est testée …

On peut donc écrire les spécifications de sa classe, dans le DSL fournit par le framework utilisé, puis écrire le code qui fera que ces spécifications seront remplies: spécifications et code restant alors en parfaite synchronization … on se rapproche presque dans un sens du “LiterateProgramming” cher à Donald Knuth ;)

Donc pour moi, au revoir TDD, bonjour BDD ;)




>/dev/null est mort … Longue vie a >/dev/null … reloaded

4 05 2007

J’ai expliqué précédemment les raisons qui m’ont poussé à fermer mon premier blog … Nous allons voir si le fait de pouvoir avoir un retour de la part de mes 2 lecteurs, ainsi que de pouvoir écrire des articles depuis n’importe où (pour peu que j’ai accès au web bien sur ;) ), va me permettre d’être plus prolixe …

La suite au prochain post :)