Either all fields are public or all fields are private.

A dependency in software can be summarized to a checksum, a location, a name and a version.

The checksum checks the integrity, the location defines how to retrieve the dependency, the name identify the dependency and the version its substitutability (major with breaking changes, minor if it has new features or bug fixes).

A summary of comments about maintaining projects over decades

About documentation:

This does not tell you however WHY things are like this. What is the idea behind how the system works? Is there a philosophy? Is there a specific reason why we do these non-obvious things? Why is the solution split up the way it is?

code definitely needs comments. Especially why a function is like that. Other feedback was to work on commit messages

In js, asserts can be used with console.assert(<condition as expression>, error message)

It is great for prototyping or use defensive programming inside a function.

Assertions often come in pairs.
Whenever you assert something, think about which distant part of the code base relies on the assertion you just wrote, and add an equivalent assertion there.
This is worth doing even in the trivial case, where the two parties are a function and its caller.
But be on lookout for more interesting cases, where the two halves of an assertion pair are separated by different implementations, or a process and time boundary.

Great advices

It is much easier to add features to reliable software, than it is to add reliability to featureful software.

Besides, it’s very easy to accidentally think you need features that you don’t actually need.

Write serialized test scenarios

How to cache? It depends of the context: push vs pull and owned vs user.

Push means that the asset is pushed to a central server and then distributed.
Pull means the asset is referenced and the central server has to “pull” the content.
Owned means it’s owned by the central server.
User means it’s user-submitted content.

Push + owned

Make everything push + owned content if possible. "It turns out, however, that you can make a shit ton of other stuff push + owned if you try a little harder. "

How does the client check if they're expired?
Use “stale while re-validate”. Ur welc’

In summary:

• store asset
• use stale-while-re-validate access patterns
• should work offline

Push + User & Pull + Owned

Handle these with hash URLs. Hash the URL and treat it immutably.
Push + User: Forum comment -> hash URL
Pull + Owned: "in-content" assets. That’s where it’s user generated content, but not owned by the server.

Summary:

• Load asset
• Use infinite TTL + hashed URLs
• Should not re-fetch across page/app reloads

Pull + User

That’s where it’s user generated content, but not owned by the server. Posting gifs into the chat is a prime example; linking a blog post and generating a media upload for that is another.

Guess what: this pattern fits for highly dynamic user-generated content, which means it’s the content users link to each other in-platform.

Stable URL, short TTL. YES, SHORT TTL. [...] Debounce + throttle? Sure. Micro-TTL? Yes. Cache? Never.

Shift is_active to something more generic: a status field, so we can expand it down the line for other parts of the state space.

Honestly, 80% of the time in these meetings I just tell people to either use an enum instead of a boolean or to make it more clear which data is events and which is state. I'm always right, it's always useful, and there's never that much fuss about it.

How to build the local-first software with the most interoperable data system: files.
How to avoid conflict while syncing them on cloud providers? Tonsky relates some strategy.

About OOP.
Notice a faisable comparison with the current AI

• IdType trait: a trait that marks a type used for database identifiers
• the read-only/read-write transaction pattern (and create two SQLite connections: a read-only and a write-only)

Composition let you implement, hand pick and choose what you need when you need it.
It allows to build to thing that fits, in opposition to inheritance. Inheritance forces to predict the future.

The key is transmitted via the hash of the URL. Smart ! The rest is encrypted on the client side.

An example is provided with the crypto API, especially subtle.

A collection of resources such as guides, blog posts, advocacy, how to's

How to create a good project architecture? Here's a feedback.

Mann kann erst skalieren, dann optimieren, wenn es ein Drittels des Tages dauert. Der erste Prozess, um PDFs zu erzeugen, ist total innefizient. Es zeigt auch, dass Optimierungen der letzte Schritt des Produkts ist. Sie haben damit lange gelebt. Die Architektur ist eine gute Beispiel für horizontale Skalierung.

Parsing increases the information in the type system. A list can be of type NonEmpty, i.e. there is at least one element.

Use a data structure that makes illegal states unrepresentable.
Push the burden of proof upward as far as possible, but no further.

and awesome guidelines to follow.

So parse "data" and return the closest type instead of only validate them.

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both.

More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

Even in single-threaded programs, it is sometimes arguably significantly more convenient to have a method that is a combined query and command. Martin Fowler cites the pop() method of a stack as an example.

Safari is using the web to create a desktop app in a very convenient way!

There’s a HTML file and a Service Worker that keeps it working offline

More about it on https://adactio.com/journal/20716

It explains the Writer monad and the Option monad.

This pattern is used for future or promise by the way.