Ca ressemble à une version open-source de Confluence ... mais en beau

Ca semble une très bonne explication de Stable Diffusion

J'ai tendance à penser que ce qu'écrivent les grands anciens de l'agilité sur la documentation est globalement à côté de la plaque, mais ça n'est que mon avis ...

Et un outil labelisé doc-as-code qui fournit un plugin maven de transformation d'asciidoc en confluence

Caché dans docToolchain, il y a un script qui prend de l'HTML généré par Asciidoctor pour le transformer en document Confluence

Le point de départ de beaucoup de mes idées de ces dernières années

ddocker run -it --rm -p 8080:8080 -v %CD%:/usr/local/structurizr structurizr/lite

La doc d'installation de Kroki dans Docker est quand même super claire !

docker run -d --name kroki --restart unless-stopped -p29000:8000 yuzutech/kroki

Une belle citation montrant bien l'intérêt qu'il y a à documenter sérieusement un projet

Une critique valide, qui peut figurer en préambule de n'importe quelle documentation d'architecture

C'est le mode d'écriture de la documentation des développeurs que je préfère. C'est simple, efficace, et ça garantit une documentation à jour ... pour peu que les développeurs soient des professionnels.

Je relirai cet article, qui est une mine d'or sur l'écriture de documents de design de système ...

Quand je lis ce document, j'ai l'impression de voir une autre forme de description d'architecture applicative se dessiner. C'est intéressant ...

Ca m'a l'air d'être une méthode d'identification des risques de sécurité qui sorte de "oulala, c'est grave, non mais tu te rends compte" tellement fréquent dans cet univers ...

Je cherchais depuis longtemps un outil pour créer des releases notes à partir de mes issues dans GitHub. Et celui-là a l'air bien.

J'aime beaucoup l'idée d'un DSL d'architecture d'entreprise. MAIS le fait que cet outil dépende de Scala/SBT et Node me paraît difficile à accepter.

Ce catalogue des codes HTTP est franchement bien mieux fihcu que celui que je consulte d'habitude (la wikipedia)

Est-ce que vous saviez que git dispose d'un système de gestion de métadonnées ? Pourquoi ça m'intéresse ? Parce que ces histoires de conventionnal commit sont des métadonnées mal cachées dans le message de commit.

Un service ... intéressant (et leur page de doc sur les différents clients AMQP est super complète

Si vous avez un jour besoin d'afficher le schéma d'une base postgres/mysql dans PlantUML rapidement, cette image Docker fait du bon boulot ...

Et avec ça, je peux écrire ma doc dans mon contrôleur Spring, et l'exposer dans ma doc, sans passer par Springfox (je n'ai rien contre, c'est juste pas mon cas d'utilisation)