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...
A bit on the sarcastic side but there's definitely some truth to it. This definitely goes against the YAGNI principle.
Good arguments around the microservices hype. People advocate for it way more than reasonable, this applies only in rare contexts.
This is a good example in my opinion: stick with simple choices as long as possible, invest the complexity where it matters.
This article is spot on in my opinion. This resonates so much with my own experience and ethos... I guess I could have written that if my prose was any good.
Interesting list of criteria about why you might not use some piece of tech. Also delves into why this is often not public knowledge.
Interesting warning about too early standardization. Don't go top-down, better go bottom-up working on each separate problem and see if something emerges.
And that's why I find hard to swallow that "microservices" is the go to answer from lots of people nowadays when you discuss architecture. There are interesting promises on paper but that requires you to ignore several layers of complexity. It's likely fine to get there at some point, but bake in all that complexity from the start? I don't think so.
Simple illustration of that software architecture pattern in Java
Very good rant which explains nicely why rewriting some software from scratch is almost never the right answer.