Les liens de la mer numérique
- Having an "inbox" notes to capture ideas in form of napkin, receipt, voice recorder
- Literature notes: When you consume content, take notes of what you don’t want to forget or what you want to use in your own writing. It is recommended to make them atomic. Make sure to include the bibliographic details, author & source at the very least, so you know where you got the idea from.
- Permanent notes: every day, you should go through the inbox and seek to refine the fleeting & literature notes. Making connections and turning them into permanent notes.
One idea = One note
One note = One idea
- Navigation: an index allows you to navigate in the zettelkasten; keyword notes can also be used as link.
Le TDD est avant tout une méthode de développement permettant de faire émerger son design et donc son code grâce aux tests
“Baby-step”, c’est la clé pour s’amuser, pas au sens d’enfantillage, mais pour prendre plaisir à développer et comprendre que notre métier est vraiment beau quand on supprime toute forme de “hasard”.
Un cycle TDD "Red, Green, Refactor" correspond une une bribe de spécification écrit sous forme de test et sa réponse. On écrit le code minimaliste pour que ce test "Red" fonctionne et passe au "Green".
Pour cela, il est recommandé d'abuser de son IDE. Par sa construction itérative guidée par les tests, TDD apporte par “effet de bord” un taux de couverture de code par les tests à 100%. Ce n’est pas ce que l’on recherche de prime abord, mais ce code coverage est là, et surtout il est pertinent. C’est ce dernier mot qui est important : cette pertinence permet réellement de se plonger dans la troisième phase de TDD.
Ensuite on refactorise pour donner plus de sens: spécifier les erreurs, de passer d'un constructuer à un builder, ... Nous pouvons nous le permettre car les tests nous soutiennent. Ils seront aussi à évoluer, par exemple pour vérifier que le builder pattern fonctionne correctement.
- Conclusion
- Key arguments
- Detailed information
Une introduction à la méthode PARA
S pour Situation, c’est-à-dire la description du contexte qui permet de donner une vision globale à votre interlocuteur
T pour Tâche, qui désigne la mission et l’objectif à atteindre
A pour Action, qui correspond à l’ensemble des actions que vous avez initiées pour réussir à réaliser la tâche
R pour Résultat, qui permet de souligner le bilan et les effets de vos actions, notamment par la mention de données chiffrées.
c’est une méthode qui force à utiliser tes vraies situations passées, les décortiquer et prouver tes compétences à travers elles.
Il semble bien fournit ce guide !
Néanmoins Scrum semble être plus que correct.
A methodology to build software-as-a-service apps
A great introduction to the lotus blossom.
I use it to get some ideas for the User-centered design methods class