@tomkemper.bsky.social
No matter what you pick, they'll start as Lvl1 Barbarian I'm afraid
December 10, 2025 at 7:49 AM
No matter what you pick, they'll start as Lvl1 Barbarian I'm afraid
Very curious about the details!
I'm very surprised that the test-suite is written by AI. I would've expected the exact opposite (human devs write specs/tests/requirements, ai devs write code that implements).
I'm very surprised that the test-suite is written by AI. I would've expected the exact opposite (human devs write specs/tests/requirements, ai devs write code that implements).
September 19, 2025 at 5:11 PM
Very curious about the details!
I'm very surprised that the test-suite is written by AI. I would've expected the exact opposite (human devs write specs/tests/requirements, ai devs write code that implements).
I'm very surprised that the test-suite is written by AI. I would've expected the exact opposite (human devs write specs/tests/requirements, ai devs write code that implements).
Recently I did just that. But that was because for a feature I needed to integrate with a couple of webhooks, and I really didn´t know in advance what kind of data I would be receiving. I wouldn´t do it if I were in control of the code putting stuff in the database.
September 12, 2025 at 1:00 PM
Recently I did just that. But that was because for a feature I needed to integrate with a couple of webhooks, and I really didn´t know in advance what kind of data I would be receiving. I wouldn´t do it if I were in control of the code putting stuff in the database.
Agreed, I'd even advise to bank on the Foreign Key integrity that such a setup allows as long as you can.
I'd be a bit more hesitant about (a lot of) joins, as they can impede eventual separation.
I'd be a bit more hesitant about (a lot of) joins, as they can impede eventual separation.
March 10, 2025 at 6:17 PM
Agreed, I'd even advise to bank on the Foreign Key integrity that such a setup allows as long as you can.
I'd be a bit more hesitant about (a lot of) joins, as they can impede eventual separation.
I'd be a bit more hesitant about (a lot of) joins, as they can impede eventual separation.
As an extreme example, if your service A calls an endpoint on service B, which in turn calls a different endpoint on A, and so back & forth a couple of times, the services are so tightly coupled you might as well throw 'm all together, starting with their databases...
March 10, 2025 at 5:42 PM
As an extreme example, if your service A calls an endpoint on service B, which in turn calls a different endpoint on A, and so back & forth a couple of times, the services are so tightly coupled you might as well throw 'm all together, starting with their databases...
I'd say that Microservices as a strategy, and its accompanying patterns, were invented to scale past team-sizes too large to realistically expect such discipline?
(but I'm a small-team-dev, so a little out of my depth here)
(but I'm a small-team-dev, so a little out of my depth here)
March 10, 2025 at 5:40 PM
I'd say that Microservices as a strategy, and its accompanying patterns, were invented to scale past team-sizes too large to realistically expect such discipline?
(but I'm a small-team-dev, so a little out of my depth here)
(but I'm a small-team-dev, so a little out of my depth here)
If I'm understanding correctly, you're saying that if each microservice just has their own little completely disconnected part of a database, that this is simpler to maintain, and it makes later cross-cutting queries easier?
Sounds completely reasonable. Requires a ton of discipline though.
Sounds completely reasonable. Requires a ton of discipline though.
March 10, 2025 at 5:39 PM
If I'm understanding correctly, you're saying that if each microservice just has their own little completely disconnected part of a database, that this is simpler to maintain, and it makes later cross-cutting queries easier?
Sounds completely reasonable. Requires a ton of discipline though.
Sounds completely reasonable. Requires a ton of discipline though.
If your services are already rrrreally tightly coupled due to API-design, I suppose it matters less.
However if they weren't too tightly coupled, chugging them into the same database (with cross-service joins/FKs) will make them so, and make it a whole lot harder to get out of that hole...
However if they weren't too tightly coupled, chugging them into the same database (with cross-service joins/FKs) will make them so, and make it a whole lot harder to get out of that hole...
March 10, 2025 at 8:49 AM
If your services are already rrrreally tightly coupled due to API-design, I suppose it matters less.
However if they weren't too tightly coupled, chugging them into the same database (with cross-service joins/FKs) will make them so, and make it a whole lot harder to get out of that hole...
However if they weren't too tightly coupled, chugging them into the same database (with cross-service joins/FKs) will make them so, and make it a whole lot harder to get out of that hole...
Driving/Driven always trips me up. Is the Driving side the side I'm driving? Or is it the side that's driving me?
And knowing I usually mix it up makes it worse, because then you get confused whether you should swap meanings just one more time to get it right... or whether you definitely shouldn't.
And knowing I usually mix it up makes it worse, because then you get confused whether you should swap meanings just one more time to get it right... or whether you definitely shouldn't.
November 25, 2024 at 8:25 PM
Driving/Driven always trips me up. Is the Driving side the side I'm driving? Or is it the side that's driving me?
And knowing I usually mix it up makes it worse, because then you get confused whether you should swap meanings just one more time to get it right... or whether you definitely shouldn't.
And knowing I usually mix it up makes it worse, because then you get confused whether you should swap meanings just one more time to get it right... or whether you definitely shouldn't.