228 private links
For simple sites, keep things manual.
Automate when it hurts to do it manually.
"Joy in the smallest things comes to you only when you have accepted death" Carl Jung says.
Because death means the end of everything, knowing that death is the end allows me to use this idea as a source of strength and resilience.
Totally agree.
I keep my life simple because I know my time is limited. Time and health are my best proxies for happiness.
How?
Mostly by saying no.
No streaming subscriptions. No gym memberships. No Instagram and TikTok. 6 years old shoes and wardrobe. No meetings if possible. No commute; I work remotely. No property; I'm a happy tenant. No trips. No great home cinema setup. Limited tooling on the computer. No notion or Obsidian if a text file + git is enough.
On the other side, relying on reddit or HN for comments is exclusive.
Simple means focused.
Yes, there’s a creative process and they allow themselves to be creative, but they do so in a very constrained environment: their office. While others chase trends, they do the thing they’re always doing.
Rust is the first language in a long tome being able to compete with C or C++.
Rust also built a market around it. Orner languages of the same category did not.
At the beginning of the century, people played around and gave all kinds of things URIs like "http://example.com/foo.rdf#color".
for one reason or another people demanded the right to be able to use http://example.net/people/Pat to denote Pat rather than a web page about Pat.
The term Resource is indeed enough for REST, but other use cases such as RDF already reserved Resource for something different.
in fact in RDF the resource was allowed to be anything at all. A class, rdf:Resource even used the term as the universal class of all things.
A more general approach, more suitable for link blogs so inclined, would be to use word count with a note on writing style. Something like “850 words, fluffy, no long words” or “850 words, tech jargon, complex sentences” would be much more useful than the “3 minutes” that most default today
TL;DR we don't care in unit tests about internal testing. That doesn’t mean shallow rendering is wrong.
I personally use them to test well separated logic and iterate over:
- write the test that make the feature pass
- implement until the code passes the test
- next feature or case or exception
- repeat.
Yes. TDD.
Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years.
However, what most people don't realize about the role consuming meat in our evolutionary development is that we weren't eating meat as frequently as we are in the modern world. We were primarily grazing and gathering, not eating meat on a daily basis, [...]
À propos de l'obésité logicielle
À propos de Strava
A mindset shift
I want to become someone who enjoys tinkering with coding and tech every day
I want to become someone who loves running and taking walks.
[...] Just enjoy the path, stay on the path, and keep becoming.
It consumes to much resources and people must have better hardware over time in order to develop....
Some thoughts about high-leverage job.
Where to start: https://www.givewell.org/about.
The website contains a lot of information: goals, how and mistakes!
First, you need to describe the intent of your code and give an overview of how it works both at a macro level (in the README / wiki) and at the micro level, by commenting functions, structures and packages. Document, document, document.
Second, give examples on how to use your code. Snippets that users can quickly copy/paste and "feel it". Even better, add comments with the expected output to your examples.
Three, write simple code.