Longwelwind

2 bulan yang laludiscuss

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.

Longwelwind

4 bulan yang laludiscuss

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.

Longwelwind

4 bulan yang laludiscuss

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.

Longwelwind

5 bulan yang laludiscuss

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.

Longwelwind

5 bulan yang laludiscuss

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!

Longwelwind

5 bulan yang laludiscuss

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.

Longwelwind

tahun laludiscuss

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

Longwelwind

2 tahun yang laludiscuss

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.

Longwelwind

2 tahun yang laludiscuss

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.

Longwelwind

2 tahun yang laludiscuss

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.

Longwelwind

2 tahun yang laludiscuss

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.

comments