Blog

Gregor Hohpe discusses Domain Driven Design in Cloud, and hits 3 important topics:

1. How the words you use enable design, and indicate what type of work culture you’re in, and incentives to use better words.
2. How bad and difficult it is for Cloud providers to keep a consistent language, and to what degree they’ve created a decent set of words to describe their services, and how they could do better.
3. How most people do NOT get how to use AWS CDK.

Learning Test Driven Development (TDD) is hard. I have a decade+ of “Test Last” “Test After” content on my blog and YouTube, none of it “Test First” until much later in my career. So here’s a 3 phase process to ease into it. I’m assuming you already know how to setup unit testing frameworks (Jest/Vitest/Mocha/Jasmine, etc) and use assertions (expect, assert, etc).

Reading the effect-ts docs, and it’s basically a Result and Option with many helper functions, a way to compose functions, with type-safety (as much as you can get in TypeScript). If you’ve ever used Folktale, Sanctuary, or true-myth, you’ll immediately know the basics. The run API reminds me of Python’s async io or Scala’s ZIO.

Attempted to get all 4 DORA metrics today from our AWS pipeline, and wow, a lot harder than I thought to both get them, AND do what I thought were simple calculations (some of the extra math ended up being fun).