11 private links
Un super exemple d'usage de Clojure pour un projet complexe.
Comme je découvre Clojure ence moment pour l'advent of code, je trouve l'idée intéressante. Bon, je ne suis pas encore au niveau de coder une vraie application, mais j'avance.
L'article est aussi un très bon exemple de décision d'architecture.
On se retrouve effectivement régulièrement à devoir décider sans avoir toutes les informations. Et ça n'est pas grave, parce qu'une mauvaise décision peut être ajustée, alors qu'une absence de décision ne fait que reporter le problème à plus tard.
Ca n'est pas le premier article que je lis sur OODA, mais celui-ci est très complet.
Encore un article sur la décision via la polarisation, c'est très chouette.
Où je découvre
1 - un modèle archi-complet de documentation de décision
2 - Que ça date au moins de 2005
Un article sacrément intéressant sur l'architecture.
Une initiation très complète à ce qu'implique réellement le rôle d'architecte. Les slides m'ont fait réfléchir à mes pratiques.
JE VEUX PRENDRE MES DECISIONS COMME CA ! J'en ai marre des comités à la noix, des discussions qui reviennent toujours en arrière, des coups foireux. Je veux des prises de décisions claires, argumentées.
J'adore cette méthode de réflexion, ça fournit des espèces de personnas applicables globalement pour à peu près toutes les décisions.
Oh la vache, ce schéma est sacrément intéressant, et explicatif de points d'achoppements typiques des progjets informatiques.
La décomposition des choix en cinq zones d'intérêt différents pour différentes personnes est vraiment très intéressante. Je pense vraiment que je vais réutiliser ce modèle de décision.
Je ne sais pas ce que vaut ce livre, mais si les exemplaires papier se revendent plus de 750 $, ça peut être une lecture intéressante ...
Slack est une forme d'enfer. Mais réussir à en tirer une aussi belle idée ? C'est vraiment chouette !
C'est une vision extrêmement intéressante des processus de décision
Ah, des adr directement le code Java, c'est marrant !
Il va falloir que je relise ça plusieurs fois, mais ça détaille bien les variantes du concept.
Au-dela du format Markdown, il y a dans ce document un très bon modèle d'ADR.
Ca aide bien à relativiser l'impact des "décisions" qu'on prend
C'est peut-être la séance que je regrette le plus d'avoir loupé à Snowcamp ...
Très bon article, qui montre bien que l'architecte est responsable des décisions architecturales, et qu'il s'appuie pour ça sur des requirements. Il manque simplement les ADR qui sont les traces des décisions.