Un très bon article sur le paradoxe de la prévention : les incidents qui n'arrivent pas ne coûtent rien, donc la structure qui les a évité n'a pas de valeur et peut être sacrifiée. Comment l'éviter ? En identifiant les moments où ces incidents auraient dû arriver et en chiffrant leur coût potentiel.
Je n'utilise pas docueye ... Mais je suis certain que ce genre de règle peut s'implémenter facilement dans Structurizr ...
Avec mon excellent collègue Logan, on a eu la chance de parler d'ADR à DevLille. Dans les deux ou trois idées qu'on essaye d'apporter, il y a le modèle ACED et Cynefin, pour décider correctement quand écrire un ADR.
Un format d'atelier utilisant C4 et le DDD (et certains formats d'ateliers agiles) pour modéliser une architecture. Ca me semble aussi malin qu'efficace.
ArchUnit est très intéressant, mais j'achoppe toujours un peu sur la définition des tests.
Et je trouve, à première vue, que Taikai fournit une ergonomie un peu plus intéressante.
Un très bon article sur des erreurs que font les gens quand ils dessinent des diagrammes d'architecture.
Je découvre dans une chouette conférence cette très intéressante page listant les erreurs faites dans la conception de CSS
L'article est littéralement en train d'expliquer pourquoi baser sa vision de l'archietcture sur le code est une bonne idée. C'est bien ... Mais bon, on le sait depuis au moins dix ans.
Un cadre d'architecture fonctionnel qui, comme à chaque fopis, semble rempli de belles et grosses définitions sans jamais apporter d'informations concrètes (et vu la tronche du truc, je parie que les détails sont payants)
Un article qui réarticule tout un tas de concepts autour de la discussion d'architecture pour en tirer une réflexion vraiment intéressante.
Je vais tester Lundi ce truc histoire de voir si les conseils sont pertinents, mais je trouve en tout cas la démarche de détermination de choix techniques ou architecturaux intéressante.
Un exemple de process de revue léger, qui semble intéressant
Une collection de lois, principes, axiomes divers, trouvée par Nicolas Frankel
C'ets bien la première fois que je vois SAP produire quelque chose d'utile ...
Ce sont effectivement des savoir-être importants quand on prétend agir à l'échelle
Un gestionnaire d'identité fournissant des fonctionnalités de proxy qui semblent permettre un déploiement proche des applications
Vu que c'est le sujet de ma prochaine conférence, il va bien falloir que je lise cet article ...
Je pense qu'il y aurait des façons plus rigoureuses d'arriver au même résultat. Mais c'est à mon sens un usage raisonnablement intéressant des limites respectives de l'homme et de la machine pour garantir une architecture correcte.
Voici pour cet ingénieur les neuf critères d'évaluation d'un langage de programmation (pour peu qu'on arrive à dépasser la question de l'identité construite par le développeur sur son langage préféré)
Oh wow, l'article est vraiment passionant sur la façon dont les questions de choix de langage, de framework, d'architecture, sont avant tout des constructions identitaires.
La psychologie se cache décidément partout ...