Idea of writing:

• Here’s a cool thing I made.
• Here’s a cool thing someone else made.
• Here’s something I just learned.
• Here’s something I want to learn that looks cool.
• Why I want to learn/use/do this thing.
• Why I don’t want to learn/use/do the thing.
• I’m in the process of learning something but I haven’t quite got it figured out yet.
• Here’s something else I discovered while learning a thing.
• Let’s learn a thing together!
• Here’s a tip, tool and/or person that helped me recently. Maybe it’ll help you too.
• Here’s a problem that’s been bugging me.
• This is what I think about work/life/the industry/the world/this UI component right now.
• Here’s an interesting thing someone else has to say. Here’s my take on it.
• I’m feeling motivated! This is what’s motivating me.
• I’m feeling unmotivated or burnt out. Here’s why.
• This is what I’ve been reading/watching/listening to recently.
• Here’s a list of things I could blog about.

Make a german article of it

Update the documentation of JSON.stringify/JSON.parse as serializer/deserializer.

#idea #project

Past a URL and retrieves some information about it.

First: check if the url is "safe"

Make it accessible #idea #project

Notes stow metadata about anything tracked by git—any object: commits, blobs, and trees.

The git project itself offers an example of git notes in the wild. They link each commit to its discussion on their mailing list.

Other folks are using notes for things like:

• Tracking time spent per commit or branch
• Adding review and testing information to git log
• And even fully distributed code review

Review notes are used by Gerrit (Wikimedia) and many google projects. For example:

commit d1d17908d2a97f057887a4afbd99f6c40be56849
Author: User <user@example.com>
Date:   Sun Mar 27 18:10:51 2022 +0200

    Change the thing

Notes (review):
    Verified+1: SonarQube Bot
    Verified+2: jenkins-bot
    Code-Review+2: Reviewer Human <reviewerhuman@wikimedia.org>
    Submitted-by: jenkins-bot
    Submitted-at: Tue, 14 Jun 2022 21:59:58 +0000
    Reviewed-on: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/774005
    Project: mediawiki/core
    Branch: refs/heads/master

There is also an extension from Google to git notes dedicated to code review: https://github.com/google/git-appraise. Request review, comment and review and merge are included.

Its authors have declared it a “fully distributed code review”—independent of GitHub, GitLab, or any other code forge.

Git notes are however a pain to use. Mhmhmhm #idea #project on top of the git note commands?

For commits, you can make viewing and adding notes easier using fancy options in your gitconfig3. But for storing notes about blobs or trees? Forget it. You’d need to be comfortable rooting around in git’s plumbing first.

Much of the value of git repos ends up locked into forges, like GitHub. Git notes are a path toward an alternative and it could make it possible to distribute the history of an entire project.

The author shares its point of view on Shuttle that needs little to nearly 0 configuration to get started.

Zerocal was the first project I deployed on Shuttle. The principle was very simple yet innovative: encode calendar data directly into a URL. [https://endler.dev/2022/zerocal/]

#project #idea improve the UI or make a custom one that calls the API
#project #idea use such API to generate other files. Contacts?

It's an initiative for knowing the people behind a website. It's a TXT file that contains information about the different people who have contributed to building the website.

A txt file is simple and fast to create and can be embedded easily with a <link type="text/plain" rel="author" href="./humans.txt">

It completes robots.txt or security.txt

Build a CLI tool, check with the other existing tools and make a UI for it. It can include a preview for example.

The project is no longer maintained, and a comparison exists with other tools: https://github.com/coolwanglu/pdf2htmlEX/wiki/Comparison

What would be a social media with 100 posts per user ?

Critics of Git, if someone had to improve from its weaknesses.

sha1 was a bad choice back then. The moral here is "treat your identifiers as opaque strings" along with "sometimes a sha1: prefix doesn't hurt anyone"

Email and names in every commits:

I guess when you read lkml, the notion of spam isn't too worrying, but putting names and emails into every commit means any time someone changes name or email, they might as well be a whole different person to the repo.
Sure enough, when you store names in the files, you have to rewrite history when someone changes email address, but in another world, you'd use a UUID and a file called .gitauthors that maps one to the other

There are two different mechanisms for almost every feature.

git forces you to make a choice. use merge and get a noisy, but representative history. use rebases and lose some of the work, but the log is a lot easier to navigate.
we could also have a version of git log that didn't make merges look like shit, but that's another problem altogether.

the unix philosophy is about building toolkits, not applications

in other words: have you ever accidentally committed inside a rebase? or accidentally committed a conflict? tough shit, fucko.
git commands are named after implementation, not use, and there's absolutely no excuse for it
flat files kind of suck if your state gets corrupted.

git is made from papercuts

there's bits where you can't check in an empty directory, or how you can set files to ignore but not files to include.

#project #idea make it better

Ok un générateur d'idées, cela arrive...

Compared with inflation, is the salary the result of a promotion or a pay rise? Does it cover the cost of inflation?

#idea #project traduire en allemand

Generate fake identities. It seems to be only available on chrome for now. #idea #project

Quitte à stresser, autant stresser précisément!

À la fin de chaque session d’écriture, mettez à jour ce décompte [de mots à écrire], et gardez éventuellement une trace de son évolution.

Plus sérieusement, "j’avoue d’ailleurs l’avoir testé comme une blague au début. Mais en pratique, c’est bien cette info (complétée par la moyenne glissante) qui m’a permis d’organiser sereinement ma rédaction et notamment mes temps de repos, en levant mes doutes sur mon avancée au quotidien.

#idea #project make it real:

1. D’abord, l’objectif : le nombre de mots total visé pour le mémoire. Ensuite, le décompte : le nombre total de mots contenus dans le mémoire à la fin de chaque jour. Et enfin, le délai : le nombre de jours d’écriture dont je disposais avant de devoir remettre le mémoire à l’école doctorale.

2. Le problème de cette information, c’est qu’elle peut donner trop de visibilité à la progression quotidienne : il ne faut pas seulement savoir si on est dans un « bon jour » ou un « mauvais jour », il faut replacer tout cela dans un intervalle de temps plus long. J’ai donc aussi créé un graphique de la progression en nombre de mots par jour sur lequel j’ai ajouté la moyenne glissante sur 7 jours.