One approach for achieving compile-time checks, might be having two different structs for alive and dead player, and have the necessary methods implemented for them respectively.

why it’s bad:

• the API is not clean. We are storing the same fields in both Dead and Alive player, while they are both just Players.
• the end-user has to know when to create an instance of Alive player and Dead player. It might be simple to guess in this example, but imagine much more complex/abstract types. If possible, our API should be responsible for when to use which type, not the end user.

Solution 3 is better with an struct that uses a state! The state determines how is the player and different functions are implemented for a player state.

Note it is similar to typescript with an interface or type such as Player<'alive'> of type Player<T> = { state: T, ...}

The idea is to set sensible typographic defaults for use on prose (a column of text), making particular use of the font features provided by OpenType.

Using monospace fonts to design based on the ch unit.

Background: https://wickstrom.tech/2024-09-26-how-i-built-the-monospace-web.html

A (somewhat opinionated) list of SQL tips and tricks that I've picked up over the years in my job as a data analyst.

A lot of Rust lectures lately. See https://video.infosec.exchange/w/p/aUTyZA8bp5b8EDeT8VaV6M

how to compile and run JS code in rust through V8

La nouvelle API Temporal, successeur de Date pour la manipulation de date.

An idea to put URL query parameters in the body pf the request.

It is useful to avoid the limitations of the URL length. Another use case is a custom DSL inside the request body.

At the end, it's a less readable than GET but more powerful.

How to Choose

• If the closure only reads from the environment: Use Fn.
• If the closure needs to mutate the environment: Use FnMut.
• If the closure needs to consume ownership of values from the environment: Use FnOnce.

Different definition of a UI component, from the minimalistic css one to the SSR full page.

As we further discuss backup strategies, please remember, that having a remote volume mounted as a primary or a secondary disk in your system means you have filesystem access to a distributed data store that you use by simply doing file operations (e.g. cat, tail, cp, touch, mkdir, etc.).

I would simply mention that features that exist in ZFS, Btrfs or XFS (not a CoW fs but has some CoW features). [...] both ZFS and Btrfs offer transparent filesystem compression, meaning even the stored, deduplicated pages can be further reduced in size.

"Thing" backup strategies:

• backup data pages in the file verbatim
• pack data pages as you copy them (byte by byte copy with database cleanup beforehand)
• dump the data as SQL commands

"How" backup strategies:

• litestream: copy the db changes depending on the WAL
• SQLite .backup command creates an exact page by page replica of the database file at the point of invoking the command.
• SQLite VACUUM INTO
• SQLite .dump
• good old cp with --reflink=always in a transaction

Another CSS reset explained