Longwelwind
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.
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.
The fairest system would be for each human being to have an equal amount of pollution they are allowed to emit.
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.
I sometimes ask Claude to read some code and generate a process diagram of it, and it works surprisingly well!
This feels funny to read, for some reasons.
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.
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.
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");
}
}
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.
* 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.
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.
Basically you represent your board game as a tree of phases through which your game progresses in.
Each node of your phase tree can contain state. At any point, your game is at leaf of your tree, and the state of the game is composed of all the states of all the nodes from the current leaf-phase to the root of the tree. Each leaf node also have a set of possible inputs describing what possible action players can take to progress into the game. This makes it really easy to handle games that have special "rare" phase that can break the flow of the game (for 7 Wonders: Duel, for example, phases where players must resolve a wonder's effect that asks them to destroy an opponent's card).
I had the idea after developing Swords and Ravens, an online adaption of A Game of Thrones: the Board Game (2nd edition), and realizing that there was a way to make a library to allow people to create board games without having to bother with the network part.
I also wrote a blog post about it: https://longwelwind.net/blog/networking-turn-based-game/
Good luck in your project!
> Don’t talk to me about collaboration when I sometimes have to turn off slack to be able to hear myself think.
Why not communicate to the people that interrupt that they should not come to your cubicle to ask their questions, and should send you a Slack message with their question instead?
And then, if you are deep into something and you don't want to be disturbed, you can mute your slack notifications.
It feels to me, from the tone of the post, that the writer prefers WFJ because it allows them to side-step issues that they could have resolved with communication. Of course this doesn't apply to the practical issues (time lost commuting, ...)
This means that if you have a CD pipeline (triggered itself by a commit) that does `terraform deploy`, you'd need to have your CD pipeline do commit _again_ to save the changes to the TF state files.
On top of that, you lose the ability to re-run a previous CD pipeline to rollback to a previous version of your infrastructure.
The goal of Git is just to store the lifecycle of a piece of software, imo. It's not the reponsibility of the repo to know the state of the deployment.
Debating on the use of the words is wasted energy. Imo, what matters the most are the concepts behind them. The same can be said about the many discussions about server-less architecture.
For NLP use-cases, you can use a vector database to index the embeddings of your texts.
For exemple, if you implement a document retrieval (a search engine like Google), you train a transformer model that takes a text as input (the content of your document) and produces a vector of number as output (the embedding). You then index your documents by transorming them to their embeddings and storing them inside your vector database.
When you want to perform a query using keywords, you transform your keywords into a vector, and then ask your vector database to send you the most similar documents, using a similary function such as the cosine function.
* Add a GPU resource requirement on one of your step
* Add an auto-scaler that adds GPU nodes to your cluster based on the GPU resource demand.
After having written the above, I realize that it might sound like that famous HN comment about how you can /easily/ re-create Dropbox yourself, which might actually prove your point that there is a need for ML-specific tools for the training part.
* Prometheus/Grafana/TSDB/... can be used to setup a model monitoring platform since you're observing metrics whether they are from an ML service or a normal service.
* Any service deployment tool can be used to deploy ML models, since they are services.
* AirFlow/Dagster/... can be used to orchestrate model training, since training a model is basically a data engineering task.
With that said, I still believe that there is space for ML-specific tools to be created.
* Model Monitoring tools (ArizeAI is the only one I've used) can be tailored to be easily usable by ML Engineers without requiring DE knowledge.
* Deploying models in production has some specifities: things like GPU support, adaptive batching, ... Those specifities can be implemented inside a model deployment tool.
* Training orchestration is the only domain where I think there's truly no need for new tools.
Let people do the mistakes once and learn the correct package name, instead of relying on a hack and potentially introduce confusion later.
It's not because it was working from a user perspective that the underlying model wasn't broken.
As someone who only uses Steam (and used to play TF2 before all the hat things, but not DotA), I still see Steam in a good way. And I actually discovered that Valve indeed created all the things you mentioned (except NFT markeplace, which I believe is an exaggeration).
I believe that it's good that EGS is trying to compete with Steam, but on the other hand, I'm scared that EGS's tactics will force Steam to use the same tactics and make it less user-friendly.