Another love letter to SQLite. It's meant to be funny but comes with plenty of good arguments and ideas as well.
There is truth here that our profession reinvents the wheel way to often. Some problem are solved, they don't need reinventing. Be careful on your dependencies though, this is where lies the tradeoff.
Since I still hear about "microservices" more often than I'd like to. Here is another piece which points the trade-offs and that really there's no one size fits all.
Interesting article applying data oriented design to parsing tasks. This is really a good approach for performance.
This is an ongoing series, but there are good insights about software architecture work in the first few articles. Shows quite well the important tradeoffs and the usual traps.
Friendly reminder that the answer is "no". You don't want to just rewrite everything, it's not just a syntactical translation, it's a long project and at best you tackle critical components.
This is a good reference on how to write design documents. It's not as easy as it sounds sometimes, and this guide contains good tips.
It's definitely easier not having to scale at all. Which is what you get when you design for local first / client side.
Queues are not magic. If they're unbounded you're in for a world of pain as load increases.
A good primer on the main architecture traits of transformer models.
Nice suggestions on how to structure larger Rust code bases. The proposed error handling is particularly neat and tidy. This is doable in other languages but tends to be more verbose.
Which means simpler models: and this is fine for most use! It's also easier to have more ethical options with the smaller and more specialised models. Let's not forget they exist even though the big industrial complex would like people to forget.
Architecture work is not only technical, you need processes to put the architecture of a project in place. That said, you can make things easier with standards to smooth the path toward the preferred types of architectures in your organisation.
Indeed, architecture work is not only technical (what is really?). You definitely need to account for the organisation and the process to actually put the architecture in place. It's not just about having pretty pictures.
A good primer about design documents. What's nice about this one is the focus on the process rather than the form of the document. Indeed what matters is the shared understanding and making sure the right decision is made.
Shows the problem with layer cakes in applications or how you might want to go toward onion architectures.
Are you sure your understand how your reverse proxy works and the impacts it can have in production?
Lots of good insights in here. Of course YMMV and some definitely depends on your context. That's a lot of dimensions to keep in mind though.
A very good talk which walks you through how to move from object-oriented design to data-oriented design. Shows quite well how you must shift your thinking and the difficulties you might encounter with data-oriented designs. I appreciate a lot that it's not just throwing object-oriented design out of the window, indeed you have to pick and choose depending on the problem space. Also it's interesting to see how C++26 reflection might make some of this easier.
Interesting model for bringing architectural and organisational changes. This is indeed at least in part political games... so you need some political capital to spend.