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...
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.