Notes

Spent a whole day writing a redaction function because I thought no other package would have array support (e.g., a.b[].c). Today, totally by accident, I stumbled upon https://github.com/davidmarkclements/fast-redact. Face the truth: nowadays, it's very, very hard to be that special.

(At the end of the day, the package didn't work to me.)

If I'm rebasing branch A on top of branch B and there's a conflict, what's "mine" and what is "theirs"? VS Code uses "current change" (which would b B's) and "incoming change" (which would be A's), including the commit message, which is wayyy clearer

In this case, B = ours, mine (current change) A = theirs (incoming change)

That's because we checkout B and then place each commit of A on top of it.

If you want to represent an empty object, use Record<string, never>.

Dear future me: next time you're tempted to use Mustache, use Handlebars. You'll do that switch anyway.

Yesterday I realized that I don't care about any particular coding style anymore. I don't care if we're going to use tabs instead of spaces etc. What I do care is having a consistent, automatically applied coding style, so that it becomes a no-brainer.

If something is a problem, we should lint and forget it. If it's not a problem, we shouln't care.

You can't rename a S3 bucket, but you can aws s3 sync s3://old-bucket s3://new-bucket and then delete the old bucket.

Sometimes you're working on a particular test and don't want to run other specs. You run your tests adding a path pattern parameter, but you're not interested on the rest of the spec also. On these situations, I used to comment all other tests, but then I discovered the .only "modifier". You can append to describe and it to restrict what should be ran. You can even dismiss the path param.

In Jest, the difference between toEqual and toMatchObject is that toEqual checks for total equality, while toMatchObject checks for a partial match. This post is a good ref.