Longwelwind

Isn't that whole point of semantic release?

Minors and hotfixes allow you to release a new version for an older release (like if you released 3.7 but you found a bug present in 3.4, you can release 3.4.1 which would be newer than 3.7), making it possible to have multiple supported versions at the same time.

Does anyone know if there will be any live feed of the earth viewed from space during the eclipse?

The name "serverless" doesn't mean that there are no servers. It means that, as a developer, you don't need to manage the server. It's abstracted out for you.

Agents use find+grep because it's available everywhere and without any configuration, but they would still be more efficient with LSP. Once LSPs will be more easily configurable for agents, they will use them.

Those kind of tools are futile endeavors to me.

If you want to use that for unit testing, then I think it would be better to mock the calls to AWS services. That way you test only your implementation, in an environment you control.

If you want to use that for local development, then I think it would be better to provision a test environment (using Terraform or any other IaC tool). That way you don't run the risk of a bug slipping into prod because the emulator has a different behaviour than the real service.

It also doesn't care about arbitrary groupings of humans (a.k.a countries).

The fairest system would be for each human being to have an equal amount of pollution they are allowed to emit.

Trunk-based development fits nicely when you have a single deployment product like a SaaS and you don't need to maintain old versions of your software. You only have one prod environment.

If you build a software that you distribute so people can deploy it themselves (a library, a self-hostable solution, ...), then you most likely semantic versioning. In that case, the best model is to use what semantic release offers.

Using an LLM to generate an image of a diagram is not a good idea, but you can get really good results if you ask it to generate a diagram.io SVG (or a Miro diagram through their MCP).

I sometimes ask Claude to read some code and generate a process diagram of it, and it works surprisingly well!

When doing advanced terminal UI, you might at some point have to layout content inside the terminal. At some point, you might need to update the content of those boxes because the state of the underlying app has changed. At that point, refreshing and diffing can make sense. For some, the way React organizes logic to render and update an UI is nice and can be used in other contexts.

> Berulis found that on March 3 one of the DOGE accounts created an opaque, virtual environment known as a “container,” which can be used to build and run programs or scripts without revealing its activities to the rest of the world. Berulis said the container caught his attention because he polled his colleagues and found none of them had ever used containers within the NLRB network.

This feels funny to read, for some reasons.

I don't recommend resolving actions on the server in any situation:

For actions that require secret information, you would filter the actions sent to the client of any secret information and make sure the code handling the action can handle both the action and the filtered actins.

For actions involving RNG, make all randomness rely on a seed. This seed would be stored server-side and passed along the action when sent to the client. This makes sure the clients can deterministically reproduce the update.

I had the same issue in AGoT:BG and I solved it by representing the state of the game as a tree. At any point of the game, the current game state is a leaf of the tree.

You'd represent this kind of choice as a child node. When the user has made their choice, the code can return to the parent node with the choice being made so it can continue with the next "step" of the game.

The way I wanted to implement this in my turn-based game engine:

If you implement the deterministic update pattern to handle state synchronisation you can add "event" inside the logic that handles updates that pause the processing allowing your animations to be played. In JS, for example:

    async function handleUpdate(update) {
        if (update.type == "sell-items") {
            this.player.inventory[update.itemId] -= 1;

            await emitEvent("itemSold");

            this.player.money += 10;

            await emitEvent("moneyGain");
        }
    }

Server-side, "emitEvents" would be a no-op. Everything would resolve synchronously.

Client-side, the UI can listen to those events to pause the updating of the game state to see the intermediary state of the game and play animations. When the animation is done, it can resolve the promise, resuming the game updating logic.

If an update arrives while an update is being handled, it can be queued so it can be played after the current update finishes.

I would agree with you, if HCL wasn't a bad language in itself:

* You can't make have variables in an import block (for example, to specify a different "id" value for each workspace)

* There is no explicit way to make a resource conditional based on variables. Only a hacky way to do that using "count = foo ? 1 : 0"

* You can't have variables in the backend configuration, making it impossible to store states in different places depending on the environment.

* You can't have variables in the "ignore_changes" field of a resource, making it impossible to dynamically ignore changes for a field (for example, based on module variables).

* The VSCode extension for HCL is slow and buggy. Using TS with pulumi or TFCDK makes it possible to use all the existing tooling of the language.

> It's annoying because, especially with MongoDB, people come into it having been sold on it being a more "flexible" database. Yes, you don't need to give it a schema. Yes, you can just dump untyped JSON into collections. No, this is not a flexible kind of database. It is an efficient one.

I really like this sentence because it perfectly encapsulates a mistake that, I think, people do when considering using MongoDB.

They believe that the schemaless nature of NoSQL database is an advantage because you don't need to do migrations when adding features (adding columns, splitting them, ...). But that's not why NoSQL database should be used. They are used when you are at a scale when the constraints of a schema become too costly and you want your database to be more efficient.