loevborg

This is fascinating. It sounds like you're building "cloud datastructures" based on S3+CAS. What are the benefits, in your view, of doing using S3 instead of, say, dynamo or postgres? Or reaching for NATS/rabbitmq/sqs/kafka. I'd love to hear a bit more about what you're building.

> You can imagine us continuing to iterate here to Step 5, Step 6, ... Step N over time. The tradeoff of each step is complexity, and complexity has to be deserved. This is working exceptionally well currently.

Love this approach

> Failover happens by missing a compare-and-set so there's probably a second of latency to become leader?

Conceptually that makes sense. How complicated is it to implement this failover logic in a safe way? If there are two processes, competing for CAS wins, is there not a risk that both will think they're non-leaders and terminate themselves?

Love this writeup. There's so much interesting stuff you can build on top of Object Storage + compare-and-swap. You learn a lot about distributed systems this way.

I'd love to see a full sample implementation based on s3 + ecs - just to study how it works.

what are the pros and cons of oxlint vs biome?

If you like Lee Pace, check out The Fall (2006). It's my favorite film, incredibly ambitious and funny and yet virtually unknown to the public. Lee's performance is incredible, as is his young co-star's.

Does anyone have experience transforming a typescript codebase this way? Typescript's LSP server is not powerful enough and doesn't support basic things like removing a positional argument from a function (and all call sites).

Would jscodeshift work for this? Maybe in conjunction with claude?

We've been using tsgo for a few months in our team and it just works (10x faster). We bumped into some small differences in behavior with tsc but it was always because we were doing something weird in our code, and it was easy to fix.

Mad props to the team, it's an amazing achievement

We're using tsgo only on the command line btw, we're not using the vscode plugin yet

I've learned more from Charity about telemetry than from anyone else. Her book is great, as are her talks and blog posts. And Honeycomb, as a tool, is frankly pretty amazing

Yep, I'm a fan.

Correct, I use uuids as branch names, to the chagrin of my teammates

And "for of" vs "for in" (the latter typically shouldn't be used)

This unsoundness behavior recently caught me by surprise - and there's an unexpected fix (using object property syntax rather than method shorthand syntax). Also - what a strange behavior by the typescript compiler!

> “For our fairytale castles, a fairytale comes true,” says Markus Soeder, a German politician representing Bavaria, in a statement shared with Reuters.

Ah yes, a German politician representing Bavaria. Just like Gavin Nüsom is an American politician representing Kalifornien.

Node and Python. It's amazing how much works out of the box - express routes, http queries, dns queries, the list goes on

As someone who recently adopted Honeycomb, it really is an amazing tool. Especially with otel auto-instrumentation, you get insights within a few hours. The dashboard / query features are very powerful and obviously stem from a deep philosophical understanding of observability. My team was shocked at how good the tools is.

Datadog by contrast seems to be driven by marketing and companies having a "observability" checkbox to tick.

Thanks for sharing!

This is my favorite alias:

    i = !git add -N . && git add -p

`git i` lets you interactively add new files as well as existing ones

Which ones? It seems eminently usable from the outside now, at least for greenfield work. The subset of Postgres it supports is most of good/core/essential Postgres. (But I haven't tried it)

You're right, stateful dependencies like DB handles need to be passed in manually, and that's a bit of extra legwork you need to do.

That seems too dogmatic. Does the fact that Foo has a static function that knows how to create its dependencies disqualify the class from being a case of DI?

    class Foo {
      private nowFn: () => Date;

      constructor(nowFn: () => Date) {
        this.nowFn = nowFn;
      }
    
      doSomething() {
        console.log(this.nowFn());
      }

      static create(opts: { nowFn?: () => Date } = {}) {
        return new Foo(opts.nowFn ?? (() => new Date()));
      }
    }

In other words, despite all the noise to the contrary, hard-coded dependencies are fine.

James explains this a lot better than I can: https://www.jamesshore.com/v2/blog/2023/the-problem-with-dep...

Why is it a pain to inject dependencies manually? I think this is because people assume for some reason that a class isn't allowed to instantiate its own dependencies.

If you lift that assumption, the problem kind of goes away. James Shore calls this Parameterless Instantiation: https://www.jamesshore.com/v2/projects/nullables/testing-wit...

It means that in most cases, you just call a static factory method like create() rather than the constructor. This method will default to using Instance.now() but also gives you a way to provide your own now() for tests (or other non-standard situations).

At the top of the call stack, you call App.create() and boom - you have a whole tree of dependencies.

Great talk, there's a lot I can relate to in here.

I find this topic difficult to navigate because of the many trade-offs. One aspect that wasn't mentioned is temporal. A lot of the time, it makes sense to start with a "database-oriented design" (in the pejorative sense), where your types are just whatever shape your data has in Postgres.

However, as time goes on and your understanding of the domain grows, you start to realize the limitations of that approach. At that point, it probably makes sense to introduce a separate domain model and use explicit mapping. But finding that point in time where you want to switch is not trivial.

Should you start with a domain model from the get-go? Maybe, but it's risky because you may end up with domain objects that don't actually do a better job of representing the domain than whatever you have in your SQL tables. It also feels awkward (and is hard to justify in a team) to map back and forth between domain model, sql SELECT row and JSON response body if they're pretty much the same, at least initially.

So it might very well be that, rather than starting with a domain model, the best approach is to refactor your way into it once you have a better feel for the domain. Err on the side of little or no abstraction, but don't hesitate to introduce abstraction when you feel the pain from too much "concretion". Again, it takes judgment so it's hard to teach (which the talk does an admirable job in pointing out).

The Chinese are warning their citizens about travel to the U.S.

> China issued an alert warning its citizens and students of the potential risk of traveling in the U.S. and attending schools there. > > “Recently, due to the deterioration of China-US economic and trade relations and the domestic security situation in the United States, the Ministry of Culture and Tourism reminds Chinese tourists to fully assess the risks of traveling to the United States and be cautious,” the ministry said in an alert.

Can't blame them honestly

Yes, I think it's fair to say that nullables are a form of test doubles. But the approach is meaningfully different from other approaches as it avoids the problems that you get from using mocks in the narrow sense of the word: you're only testing against the behavior of the mocks (not the real code) and you need to keep updating the mocks as the system changes, which adds maintenance cost.

I'll give it a try.

The beauty of the nullable approach is that when you're testing the system under test (SUT), you're testing it together with its dependencies. Not just that - you're running the real production code of the dependencies (including transitive dependencies!), just with a off switch toggled.

What the off switch does is really just prevent side effects, like making actual HTTP requests to the outside world or reading bytes from the file system. Using embedded stub makes this a breeze (another revelation for me).

For example, while building the "/v1/add-account" endpoint, you write a test for the request handler function. If you write this test using Shore's approach, you'll exercise the whole tree of dependencies, down to the leaves.

This is what is meant by sociable tests - the SUT isn't isolated from its dependencies. It's the real code all the way down, except that you're calling createNull() instead of create() to instantiate the classes. There are many benefits here, but to me the most important ones are: (1) you don't need to write mocks as separate classes, (2) you can catch errors that arise in the interplay of the various classes or modules and (3) as a result you get a lot more confidence that everything is still working after refactoring.

A sociable microtest is a little like an integration test, but you don't exercise any out-of-process dependencies (perhaps with the exception of the RDBMS) so the tests run in milliseconds rather than seconds.

You commented elsewhere that you're worried about the separation of test code and prod code. Yes, this is a bit of a holy cow that I also had trouble adapting to. It turns out, having test-focused code mixed in with your prod classes is totally fine. I'd perhaps prefer a cleaner separation but honestly it's not a big issue in practice.

I can say without exaggeration that this article changed the way I write software. Many of the concepts are interesting by themselves (embedded stubs, nullables, sociable tests) but together these patterns form a strong approach for writing fast-running tests.

At first I wasn't sure how well this was going to work, but 30,000 lines later I can see how Shore's approach applies beautifully to real-life projects.

The only thing I'm struggling with is getting the rest of the team to adopt Testing Without Mocks. It takes a bit of effort to learn how to use it correctly.

A truth bomb if I ever saw one - thanks for articulating this so clearly

Congrat on the announcement, this is a great achievement!

Wonderful report! So now we know how long it takes to solve all of the problems: 729 hrs.

SICP is hard to work through even if you're just reading but wow, the exercises are on another level! I wonder how it compares to, say, a physics or biology textbook