Indeed, in some type of projects people tend to turn to Dependency Injection Frameworks a bit blindly (especially true in the Java world). Still there are other patterns which give similar benefits without less headaches. That's worth investigating if this fits your context before picking up a framework.

Interesting position from AMD regarding the race on the next super computers. They're all being caught up by energy efficiency so it'll need to be addressed both at the processor architecture level but also at the software architecture level. How we design our computing tasks will matter more and more.

Interesting explanations of the main drawbacks of microservices. Nothing is magical so you need to know what you loose, in this case this is mostly about increased coordination efforts and latency in feature availability.

Nice demonstration that web frontend can and should be organized like a regular GUI application (like a desktop application for instance). This will bring the same benefits in term of maintainability and modularity.

I'm more and more tempted by this kind of approach. Managing architecture models using code seems fairly neat. That said I wish we'd have better free software tooling for that, I find it still fairly limited. Maybe I should check out the Haskell library which is mentioned.

Excellent piece, looking back to history to justify why microservices are mostly a fad. Check what your needs really are and depending on them pick the right way to decompose the problem or organize your teams.

Good piece. I like how it frames the debate, asking the right questions on where might be the assumptions on how testing is done.

A good set of skills to develop to bring technical changes to a project. It doesn't need to be overwhelming or a fight. If you doubt, if you have empathy and if you slice the proposals it can become doable and help the people around you.

Nice explanation of the Mastodon architecture, how it propagates messages and interactions or how it scales.

Don't believe claims about Rust (or any other options in fact) being a language for universal use. It has a few spaces where it shines and others where it'll be a drag. Picking the right language and stack is a multi-factor decision process where the technical advantages of the language itself say less than half of the story.

There are indeed a few architectural problems with the Fediverse as it is. Can this be solved? Hopefully yes.

OK, this is funny. Clear over-engineering non sense for the sake of it.

Very good primer on Conway's Law by Martin Fowler. Definitely recommended, obviously this is just a start and requires diving deeper in the topic.

A bit messy sometimes and a few arguments seem weak to me. Still the core message holds: don't let a framework rule your project.

Very interesting post about the history of UML and the MDA approach. Clearly MDA and UML v2 was the beginning of the end for UML. That's too bad, I find UML still useful for sketching and communication between humans.

A good list of tools for making diagrams in various situations.

Nice primer of important characteristics of databases and transactions. With doodles so I'm biased. ;-)

Interesting view on the state of our industry regarding complexity. Don't despair!

The current microservices obsession not only invite undue complexity in systems, it also bring unprepared developers into network related traps. This is a nice summary of the common misconceptions around this.

Interesting conversation around complexity in code bases. I especially like the point about imagination getting out of control and getting us into speculation. This is indeed often a reason for unwarranted complexity. That's why you need to always keep the context in mind to make your choices. Also indeed fascinating to me is our ability to forget and reinvent something which was already there years ago. We really need more frameworks where we understand what's going on all the way through...