JelteF

Scrolling around when claude is "typing" makes it jump to the top

It's kinda funny that an article complaining about blurry rendering, is written using one of the most illegible fonts I've ever seen.

It's the most representative sample size if you're interested in your own performance though. I really don't care if other people are more productive with AI, if I'm the outlier that's not then I'd want to know.

There's a huge difference between endangering other people vs endangering only yourself.

Wait... Did you misunderstand this comment? Or are you saying grep caught up with ripgrep now?

I learned about the --first-parent flag of git blame recently. It allows git blame to work well in repos that use merge commits.

I was forced to use the dokuwiki, but I very much disliked editing stuff in the web interface. Having a filesystem interface to the wiki system allowed me to create and edit pages using vim , which I like to use for writing.

Quite some years ago I created a Python FUSE filesystem[1] to to interact with dokuwiki (a wiki system).

It's built on hde llfuse[2]. But that required implementing a bunch of low level APIs that were not really related to dokuwiki. So I created easyfuse[3][4] as a wrapper, which implemented the things that were unrelated the dokuwiki implementation. If you're interested it in building a FUSE system it might be worth looking at.

[1]: https://github.com/JelteF/dokuwikifuse [2]: https://pypi.org/project/llfuse/ [3]: https://pypi.org/project/easyfuse/ [4]: https://github.com/JelteF/easyfuse

I actually think the wall clock time that is used here is a more useful metric here. Using as few keystrokes is not necessarily most "efficient" in time if you have to think longer about which ones to press.

Except Apple doesn't take a 30% cut for every transaction in the PayPal app

The most effective way I've found to get other people to "write" good commit messages is by changing the "Default commit message" for squash merges on the GitHub repo to "Pull request title and description". [1]

That fixes the "Squashing, when you have 100 crap commits, and then not re-editing the message is a crime" item, because suddenly not re-editing will give you a fairly useful message. This ofcourse assumes the PR description is useful, but I've found it much easier to convince people to write a decent PR description than to write decent commit messages.

[1]: https://github.blog/changelog/2022-08-23-new-options-for-con...

One of the authors of the patch here. Two reasons:

1. This config option approach was extremely easy to implement

2. Because making this auto.conf read-only would break many existing tools around Postgres that write to auto.conf

I wanted to clarify that I (Jelte, the author of the final patch) work at Microsoft. So, it's definitely not just one company seeing benefit in this feature. Arguably Microsoft is a cloud company too though, but honestly most of the active contributors to PostgreSQL work at a "cloud company".

Luckily that's something that you control client side so you can simply be consistent about that yourself.

My personal favorite additions to my git config are using delta[1] as my pager for much more readable and syntax highlighted diffs. And adding the following alias, which means I no can always check out to the default branch of the repo, no matter if it's called master/main/develop/whatever

    [alias]
    checkout-default = "!git checkout $(git rev-parse --abbrev-ref origin/HEAD | sed 's@^origin/@@')"

[1] https://github.com/dandavison/delta

You can put this in your .gitconfig and do 'git checkout-default' to always checkout the default branch of the repo you're in, no matter what it's called:

    [alias]
    checkout-default = "!git checkout $(git rev-parse --abbrev-ref origin/HEAD | sed 's@^origin/@@')"

Disclaimer: I work at Microsoft on Postgres related open source tools (Citus & PgBouncer mostly)

Microsoft is heavily investing in Postgres and its ecosystem, so I wouldn't be extremely surprised if we would do this. We're definitely building things to combine AI with Postgres[1]. Although afaik no-one is working actively on query generation using AI.

But I actually did a very basic POC of "natural language queries" in Postgres myself last year:

Conference talk about it: https://youtu.be/g8lzx0BABf0?si=LM0c6zTt8_P1urYC Repo (unmaintained): https://github.com/JelteF/pg_human

1: https://techcommunity.microsoft.com/t5/azure-database-for-po...

Someone signing up with a wrong email

SwiftKey is still the only keyboard with an autocorrect that's actually really helpful, instead of actively messing up what I'm writing. But only if you (counterintuitively) turn off the "autocorrect" checkbox in the settings. Because then you will always have 3 distinct options to choose from (instead of middle and left sometimes being the same). Apparently you can install SwiftKey on iOS too (although I've never tried it).

Were you successful? I spent a lot of time too, but never got "go to definition" to actually work well.

Could you explain in what scenario you think it is better to have a display show two half images slightly faster (milliseconds) than one full one?

Alcohol also reduces the level of social awkwardness quite a bit that many people in the software engineering field exhibit. Which can be quite helpful in making new friends or finding a partner. I'd expect a significant percentage of people would not have been with their current partner without alcohol.

Microsoft is turned remote during covid without mandatory RTO so far.

Disclaimer: I'm working remotely at Microsoft

Zeekraal is really nice in lots of dishes. It goes well with at least pasta, patatoes and salads.

PgBouncer maintainer here, so obviously biased. But I think currently PgBouncer should still be the default connection pooler that you choose. There's a few newer options: Odyssey, pgcat, and supavisor. But all focus on a solving 1 or 2 specific problems that PgBouncer did not solve well, while not solving many of the other problems that PgBouncer does solve. So if you have the exact same requirements as the authors of those tools, then switching might be good. But otherwise you should probably continue using PgBouncer.

Supavisor specifically is too immature for general usage IMHO. It's missing some really core functionality like query cancellations: https://github.com/supabase/supavisor/issues/174 Also it's now the only connection pooler without prepared statement support.

I did a talk on this exact topic at PGConf NYC recently. My slides are here: https://github.com/JelteF/slides/raw/main/2023-10-05-future-...

Yeah, okay of course you can take it to far. But in the general case I would not want to discourage people from opening "trivial" PRs. Since those are the PRs that cost me the least time to manage, while still improving the project (even if it's by a small amount).

Personally as an open source maintainer I like the typo/wording fixes/automated refactor PRs the most. There's almost no effort needed from my side to review them, so I almost always merge those very quickly. It's the PRs that implement huge are the ones that you take the most time reviewing/discussing, and thus those are the ones I put off looking closely at.

These are the two relevant patches that I know of (there might be more):

1. https://github.com/postgres/postgres/commit/3838fa269c15706d...

2. https://github.com/postgres/postgres/commit/121d2d3d70ecdb21...

It causes much less CPU overhead on the receiving side of a copy when receiving big JSON blobs.

Pgbouncer maintainer here. Overall I think this is a great description of the tradeoffs that PgBouncer brings and how to work around/manage them. I'm actively working on fixing quite a few of the issues in this blog though

1. Named protocol-level prepared statements in transaction mode has a PR that's pretty close to being merged: https://github.com/pgbouncer/pgbouncer/pull/845

2. SET/RESET tracking in transaction mode. For this we need some changes in the postgres protocol to ask for postgres to tell pgbouncer about setting updates. This is being worked on here: https://www.postgresql.org/message-id/flat/CAGECzQQOOhH1Rztu...

3. The single threading issue can be worked around by using multiple processes that listen on the same port using so_reuseport=1 https://www.pgbouncer.org/config.html#so_reuseport

4. The pg_dump issue can actually be solved already by installing the Citus extension and using track_extra_parameters (otherwise you have to wait for the same postgres protocol addition that's needed for the other SET/RESET commands) https://www.pgbouncer.org/config.html#track_extra_parameters

There's many uses for random numbers where cryptographic random is unnecessary, but where different runs of the program should use different pseudo random sequences.