vous pouvez soutenir ma proposition d’un audit par la Cour des Comptes de l’usage fait du budget de la CNIL

Just do whatever interests you now. Don’t seek a story of purpose to guide or label your interests. [...] Focus on what fascinates you, even if it’s uncharacteristic. There is no purpose because there is no line connecting moments in time. There is no plot. You are not a story.

A future vision of the work.

1. Leaders who determine Policy
2. AI that gathers State from everywhere
3. Everything is done according to SOPs
4. SOPs are regularly updated
5. GOTO

L'instance Mastodon du CCC à un éléphant qui lance la fusée du CCC au lieu du simple avion en papier.

(via https://social.atypique.net/@quota_atypique/113210687627716459)

Calcul du coût des contributions en €

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.

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