J’ai récemment relu le livre Getting Things Done de David Allen, et j’en suis arrivé à la conclusion que j’étais passé à côté de ce qui fait sa force :-)

J’avais bien assimilé « il faut écrire tout ce qui nous passe par la tête pour garder l’esprit clair » mais j’ai oublié d’autres points qui sont pourtant tout aussi importants.

Suite à cette nouvelle lecture, j’ai commencé à me rédiger une petite note personnelle (notamment pour m’aider à affiner ma compréhension) mais j’ai finalement décidé de vous faire part de ma réflexion :-)

Note : je ne prétends pas donner ici un cours accéléré de GTD. Je livre uniquement ma pensée sur certains points précis et tente d’expliquer pourquoi ils me semblent importants. En cas de doute sur n’importe quel point, référez-vous au livre Getting Things Done. De même, si vous trouvez un désaccord entre cet article et le livre de David Allen, ce dernier à raison :-)

Pour ceux qui aiment les échecs, je me propose de vous faire découvrir (si vous ne connaissez pas déjà) le site Lichess.org.

• In Java (SimpleDateFormat), the date format “YYYY” returns the “week based year”
  • The week based year is not always equal to the year (“yyyy”).
• The format (specially “Y”) depend on the library you use. Read the doc when:
  • you have some doubts
  • you just changed date (formatting) library
  • you didn’t read it for some times
• Week based years are cool, but not when classic years are expected

Un de mes meilleurs souvenirs de fac fut le cours de Scheme, où nous avions notamment implémenté un interpréteur de Scheme.

Un des exercices que nous avait donné notre prof — et qui m’a particulièrement marqué — fut de tenter d’implémenter les listes chainées (structure de base de Scheme) en utilisant uniquement les éléments du langage que nous avions implémenté (à savoir lambda, apply, eval).

Autrement dit, on nous demandait d’implémenter une structure à partir de fonctions… et uniquement de fonctions. Impossible donc d’utiliser un simple tuple.

Si l’exercice vous amuse, je vous laisse y réfléchir, revenez quand vous aurez trouvé (ou que — comme moi à l’époque — vous aurez abandonné :p).

C’est bon ? Ok, place aux spoils.

La solution est assez élégante : utiliser une fermeture (qui se charge donc de stocker les données — c’est sa définition), et lui faire accepter une fonction qu’elle appellera avec les données. Si ça vous semble obscur ne paniquez pas, j’expliquerai plus bas.

J’ai récemment voulu recréer une implémentation basée sur ce concept, mais dans le langage que j’utilise maintenant : le Scala.

J’ai été confronté à un problème auquel je n’avais pas pensé : quel type utiliser pour définir cette implémentation ? La réponse qui parait évidente n’est en réalité pas utilisable (explications plus bas). Heureusement, halcat0x15a m’a gentiment aidé en me faisant découvrir forall, un joyau de Haskell (rapporté par Scalaz dans la JVM). (note perso : pour communiquer, nous avons parlé un tout petit peu en japonais/anglais, et beaucoup en Scala :p).

Avant de voir la bête en question, je propose de se pencher sur ce qu’est une implémentation orientée lambda-calcul des listes chainées.

Git permet de modifier son comportement de plusieurs manières. Vous pouvez bien entendu utiliser les options de chaque commandes, mais aussi modifier la configuration de l’outil.

Il est ainsi possible de spécifier que pull doit automatiquement utiliser l’option --rebase, ou bien que push ne peut pas être appeler sans arguments.