Par manque de temps, je ne vous propose que 3 articles cette semaine ! Structuring your Infrastructure as Code, The basic reasons I expect AGI ruin, Zero dependancy Pub / Sub system with PostgreSQL
how do I structure things in a way that scales well and stands the test of time? […] In my day to day role as a Solutions Engineer at Pulumi I get to answer this question a lot.
[…]
This blog post is designed to detail my high(ish) level thoughts on the concepts and principles I like to use, and why. As we explore these concepts, I’ll talk about some of the lessons I learned from my time in configuration management and the myriad IaC tools I’ve used before today.
A lot of the concepts in this post are focused on Pulumi, but lots are broadly applicable to other tools.
La structure au delà de Pulumi m’intéresse, mais je sais que l’un d’entre utilise précisément cette techno ^^
Si vous avez loupé la nouvelle et vous demandez à quoi fait l’auteur faire allusion en disant « everything is great in the IaC world now, right?! », voici un lien.
I’ve been citing AGI Ruin: A List of Lethalities to explain why the situation with AI looks lethally dangerous to me. But that post is relatively long, and emphasizes specific open technical problems over “the basics”.
Here are 10 things I’d focus on if I were giving “the basics” on why I’m so worried
Un article alarmiste sur les STEM-capable artificial general intelligence, et malgré l’intention de l’auteur, le résumé est encore long ^^’ J’ai malgré tout trouvé intéressant chacun des points qu’il soulève, notamment car l’auteur reste plutôt réaliste quant à l’état actuel des IA, et que les projections sont intéressantes même sous l’angle de la fiction (attention les notes de bas de page représentent le tiers de la longueur totale de la page, mais ne sont pas inintéressantes)
What I'm proposing at our company is that we leverage the technologies we already have (PostgreSQL & NodeJS) in order to not increase system complexity - as opposed to using a tool such as RabbitMQ (not to say that RabbitMQ is bad).
By using PostgreSQL's
LISTEN / NOTIFYfeatures, you have everything you need in order to have a high-performance, fault-taulerant pub / sub system.
Petit article sur un choix d’architecture pas déconnant pour leur contexte. L’auteur semble bien avoir en tête l’impact des coûts de maintenance d’une nouvelle dépendance, et trouve un moyen simple à mettre en place et surtout à maintenir dans le temps.
