Un état des lieux intéressant des outils utilisables autour des LLM
Parfois, avoir des textures de fond murales, c'est sympa. Et qui fait ça mieux qu'un architecte ?
La formalisation d'une gestion des connaissances personnelles vraiment bien faite.
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.
Un superbe article expliquant fort bien pourquoi htmx est écrit en pur Javascript sans aucune des fonctionnalités de Typescript. C'est un vrai essai d'architecte, parce les décisions techniques qui y sont expliquées sont des conséquences de décisions liées au métier.
Un très bon article sur la cartographie et son exploitation dans les applications de géolocalisation. Et comme c'est ploum, il y a évidement un à-priori (que je partage) pour l'open-source
Complètement d'accord. Organiser vos packages en couches n'a aucun sens, aucune cohérence. Organisez plutôt votre code selon les fonctionnalités métier.
Une réflexion très intéressante autour de Piège de Cristal et des différentes façons de se déplacer dans un bâtiment.
Une liste de livres gratuits et qui m'ont l'air particulièrement intéressants
Je n'aime pas Lombok. Mais cette plongée dans les entrailles de l'outil est particulièrement éclairante.
Je n'avais pas vu cet article qui explique bien l'intérêt de l'approche simple promue par le modèle C4. C'est le genre de retour qui me fait plaisir (sans doute parce que j'ai investi beaucoup de temps professionnel à monter en compétence sur ce sujet)
L'impact du déploiement sur des edge servers (chez cloudflare et compagnie) sur l'architecture d'un système est assez important.
Ca fait bien réflécihr cet article sur l'intérêt d'agir un peu comme IKEA
Effectivement, ce qu'on appelle MVC dans les architectures web n'en est pas
Il y a là-dedans une ou deux idées absolument fabuleuses
Une citation très intéressante : si vous réfléchissez correctement à votre architecture, vos diagrammes ne vous apprendront pas grand chose. Mais si vous n'y réfléchissez pas, vous ne penserez pas à produire des diagrammes qui vous sortiront des ennuis.
Evidement que cette citation m'interpèle
Un livre d'exemples d'architecture logicielle
Partie des informations de ce canevas se trouve. Dans le modèle de documentation d'architecture de Simon Brown. Mais je dois reconnaître que la présentation très graphique peut aider dans des contextes où il faut être synthétique.
Très bons conseils sur l'architecture et la documentation qui doit aller avec (mais n'oubliez pas, les diagrammes ne donnent pas l'histoire du système)
Ca ressemble à un sujet que je prépare très sérieusement
Très bon article sur ces sombres histoires de haute disponibilité, et sur ce qu'elles peuvent réellement signifier quand on bâtit des systèmes complexes.
Gregor Hohpe est extrêmement intelligent et ses interventions sont souvent très enrichissantes. Celle-ci me paraît toutefois souffrir de trop de hauteur de vue ...
Ca se conférence, ça, non ? Je lis l'article, et je me dis qu'il est parfaitement vrai et totalement faux.
C'est exactement ce que je dis dans chacune de mes interventions
Une discussion très intéressante sur les différentes acceptations du rôle d'architecte.
Encore un système événementiel pour Postgres. Manifestement, ça doit être facile.
Un très bon site dédié aux problèmes liés à la mise en place d'une architecture événementielle à l'échelle d'un système d'information. La plupart des questions posées sont très justes.
Encore un slide à ajouter dans ma présentation de mercredi prochain
Evidement que je suis d'accord avec Gregor Hohpe ! aider les développeurs à débugger est utile pour les développeurs (parce qu'on apporte de l'expérience et un regard différent) mais aussi pour les architectes (parce qu'on voit concrètement le système qu'on étudie habituellement de façon abstraite)
J'ai vu cet excès de microservices il y a peu, et c'est une vraie douleur à maintenir ... quand ils sont mal définis (et les microservices sont très souvent mal définis)
Un moteur de recherche de mèmes utilisant ElasticSearch (évidement) mais aussi une ferme d'iPhones utilisés comme OCR (parce que Tesseract, ça marche moyennement en fait)
Je n'ai lu que le début de la discussion, et je sais qu'il faut que je la lise en entier, mais rien que les trois premières réponses lues sont fascinantes
L'article n'est pas vraiment surprenant pour moi, mais il annonce clairement pourquoi la plupart du temps les microservices sont une mauvaise idée. Et ça vaut toujours la peine de le rappeler.
Un guide bien complet sur la documentation d'architecture. Ca va me servir avant la fin du mois ;-)
Je n'ai que rarement vu ou lu quoi que ce soit articulant aussi bien les cartes de Wardley, le DDD, les team topologies dans le but de livrer vite et bien. C'est un présentation incroyablement instructive.
Des conseils utiles quand on est en position d'influence
Ce que dit Simon Brown est toujours intéressant. Cette présentation là est vraiment fascinante dans ce qu'elle dit sur les dérives dans la mise en oeuvre de l'agilité, ou l'incapacité des équipes à comprendre ce que peut être un diagramme d'architecture ayant du sens. A voir pour tous les architectes applicatifs. (je retiens d'ailleurs l'idée de scorer les diagrammes/modèles pour pouvoir les améliorer).
Oh, j'aime vraiment beaucoup cette idée d'architecte qui partage le savoir, plutôt qu'un architecte qui code.
Une liste de conseils "de bon sens" (je me méfie beaucoup du bon sens, il fait brûler les sorcières). Les conseils qui sont donnés ici sont avant tout des conseils de pragmatisme : résolvez des problèmes clairs, et clairement exprimés, plutôt que de vous enfoncer dans des généralités insolubles.
Comme je dis toujours, pour réécrire un système, il faut pouvoir en reproduire les fonctionnalités ... et les bugs (et souvent, les bugs sont mal connus)
Quelques rappels de bon design de base de données.
C'est une vision du rôle d'architecte que j'aime beaucoup.
Je vais garder cette citation dans un coin, parce que ça me semble une réflexion très pertinente sur ce qu'on choisit de mettre dans un diagramme ou pas.
Une belle explication de ce que doit être une stratégie d'observabilité "efficace"
C'est une vision alternative à ce que je fait dans aadarchi, mais c'est intéressant ... et assez stimulant, je dois dire.
Vous aviez déja entendu parler de ce canevas de documentation de microservices ? Ca ressemble à un mélange de CIPOC et d'openAPI. Est-ce que c'est utilisé ?
Encore un manifeste ? Oui, encore un, mais qui reprend la plupart de mes pratiques architecturales
J'ai effectivement un curieux sentiment de déja vu, où le YAML remplace le XML
Un guide de référence sur les architectures orientées données. C'est très complet.