Nice!

See also https://lichess.org/

Big Tech app stores are walled gardens where a single gatekeeper decides what gets in. Powered by Nostr, Zapstore is open source, permissionless and censorship-resistant. Anyone can publish and switch relays. To preserve quality in an open network, we use web-of-trust and other metrics to surface signal and obliterate spam.

The economy is important because we don’t care enough about one another and our environment.

If we did, we would figure out how to treat each other well, how to grow individually and collectively, and how to take care of our environment in the process. With or without “the economy.”

Instead, we’ve focused so much on property and trade and money and economics and got so accustomed to money as something we can exchange into anything we want, that we've forgotten both what we need (like healthy communities and a healthy environment) and that alternatives exist.

With property, trade, money, economics having long been ubiquitous and all everyone ever worries and talks about, we have nearly fully alienated ourselves from each other.

Add to this our crisis of trust and truth, and we end up with a vicious circle: Because we’re increasingly alienated from each other, we find even more solace in money as the means to exchange it into anything we need or think we need.

The world is literally heating up in consequence.

What’s the answer?

Let’s make sure everyone is being taken care of.

• Indexing into a vector: prefer better pattern matching or raw array with index safety instead
• Lazy use of Default: initialize all fields instead
• Avoid fragile trait implementations that pass silently on changes
• From traits must be infaillible, use TryFrom if any error can occur. Make it explicit.
• Avoid non-exchaustive matches (with _ =>)
• Use decriptive names for unused variables with the _ placeholder.
• Avoid temporary mutability and make it explicit instead: let mut data = ....; .... ; let data = data
• Defensively handle constructors with #[non_exhaustive], so creating an raw instance of a struct should be prohibited outside constructor functions.
• Use #[must_use] to avoid unused instance of the struct.
• Avoid boolean parameters and in case of need, prefer enums.
• Use Clippy lints:
  • clippy::indexing_slicing
  • clippy::fallible_impl_from
  • clippy::wildcard_enum_match_arm
  • clippy::unneeded_field_pattern
  • clippy::fn_params_execussive_bools

Use cases for inherit(). They can be good but I don't see a need currently

There are great animations of ease-in, ease-in-out, ease, spring and bounce. The latest two can not be animated with Bézier curves as other common animations.

To get spring and bounce effects, the linear() function can be used. The linear() function takes a set of numbers, with 0 representing the starting value and 1 representing the final value.

Easing wizard or the Linear() Easing Generator can help.

Revue des différents moyens de protéger son serveur contre les bots IA.

JSON module imports became baseline: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import/with:

import data from './data.json' with { type: 'json' };

and lazy-load it with:

const { default: data } = await import('./data.json', {
  with: { type: 'json' },
});

It makes sense to use JSON module imports for local static JSON resources where you need all/most of the data within. Particularly since bundlers can understand JSON imports, and bundle the object with other modules. That isn't possible with fetch(), unless you use some pretty hacky plugins.

Generally, I try to turn any "fetch-and-process" logic into a Vite/Rollup plugin, so it happens at build time rather than runtime.

1. Keep things short and remove filler content
2. Don't ask for too much.
3. Presume people are busy.
4. If a request blocks you, you're asking too late.
5. Absolutely never make it personal.
6. Be descriptive and don't presume prior knowledge.

Examples are provided after these rules.

Building up means starting with a tiny core and gradually adding functionality. Sanding down means starting with a very rough idea and refining it over time.

There are a few rules I try to follow when building up:

• Focus on atomic building blocks that are easily composable and testable.
• Build up powerful guarantees from simple, verifiable properties.
• Focus on correctness, not performance.
• Write the documentation along with the code to test your reasoning.
• Nail the abstractions before moving on to the next layer.

The alternative approach, which I found to work equally well, is “sanding down.” In this approach, you start with a rough prototype (or vertical slice) and refine it over time. You “sand down” the rough edges over and over again, until you are happy with the result. [...] I find that this approach works well when working on creative projects which require experimentation and quick iteration.

When using this approach, I try to follow these rules:

• Switch off your inner perfectionist.
• Don’t edit while writing the first draft.
• Code duplication is strictly allowed.
• Refactor, refactor, refactor.
• Defer testing until after the first draft is done.
• Focus on the outermost API first; nail that, then polish the internals.

Both variants can lead to correct, maintainable, and efficient systems. There is no better or worse approach. However, it helps to be familiar with both approaches and know when to apply which mode. Choose wisely, because switching between the two approaches is quite tricky as you start from different ends of the problem

Les entreprises d'IA majoritaires gèrent l'infrastructure et le développement de l'IA. Cela profite aux monopoles, et aux États-Unis. Même si d'autres entreprises émergent, les

Les IA sont instables, puisqu'elles ne peuvent permettre la confidentialité des données traitées. Le cas de Signal est pris en exemple: l'agent peut divulguer des messages confidentiels s'il y a accès.

Les entreprises d'IA sont valorisées, mais elles ne font aucun bénéfices.

Que faire? Premièrement, appliquer le RGPD.

Cache-Group-Invalidation invalidate a cache by name.

Pour maximiser la réutilisation et la transparence, tout logiciel développé conjointement est par défaut publié sous licence libre et open source.