gcarvalho

What does AWS get out of this? Couldn't they build their own offering on top of DuckDB, just like MotherDuck has been doing?

Buying the team and having them all quit is such a bad outcome for AWS, especially they would not keep any of the IP, which is owned by the DuckDB Foundation. I don't think they would be that short-sighted.

I don't mean to be dismissive of the work done by the team which just resigned, and hope they get back on their feet.

But also out of those 6y the core team did not exist for ~5y, apparently. How is it a highly ignorant reaction?

> with every version introducing a bunch of new default rules which you then have to deal with immediately

According to the original post

> Ruff's default rule set was last modified in v0.1.0

Which was over 2 years ago.

https://github.com/astral-sh/ruff/releases/tag/v0.1.0

To be fair, if I submit changes and don’t notice I added .vscode / .idea / my_notes.txt / .DS_Store / .swp then it was a sloppy job and I shouldn’t expect the project to adapt to ignore every possible garbage file so that I can continue carelessly “git add .”-ing

I assume that’s why some open source maintainers don’t bother either - if you haven’t even looked at your diff before submitting then why should they?

I do the same sometimes, but a one-off clone is not quite the same as maintaining a "local remote" and pushing refs to it.

> it's positioning itself as a drop-in replacement for SQLite

While SQLite is often used for comparison (“SQLite for OLAP”), I’ve never seen DuckDB market itself as a “drop-in” replacement. Where did you see that?

> my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences

I have actually seen proper capitalization and correct conventional-commit types to correlate very well with the author being intentional and the patch being of good quality.

e.g.

- (a) chore: update some_module to include new_func

- (b) feat: Add new_func to handle XYZ case

Where:

(a) is not a chore, as it changes functionality, is uncapitalized and is so low-signal I can probably write a 10 line script to reliably generate similar titles.

(b) is using the correct "feat" commit type, capitalized and describe what this is for. I expect the body to explain "why", as well, and not to reiterate the "how" in natural language.

This is just my experience, but I've seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.

Don't forget about dmypy, the daemon version of mypy.

https://mypy.readthedocs.io/en/stable/mypy_daemon.html

I was never very good on FPS games, but during pandemics I would play often with friends.

One day I pop up a practice map in cs:go where one of the challenges is shooting a fixed target after it turns green. If you don’t do it within 250ms or something (nothing crazy in terms of human reaction time), then you don’t score.

I was flabbergasted to see myself miss every single time. My friend even told me “dude, are you pretending? How are you so slow?”

So the next day I got a new mouse and what do you know, I’m actually responding in time, and scored most of the time when the rectangle went green. Just the mouse was not registering it fast enough.

Of course, that didn’t translate into such a huge boost in actual gameplay, but it’s impressive how that made me consistently miss. Likely it had some crazy 50ms+ lag.

> Only at small scales are full stack engineers valuable.

Seems like the ideal career is to start somewhere big and successful enough that allows you to specialize (after some poor generalists sabotaged their own careers by making it a thriving environment for specialists). Because even small scale businesses think they should start by hiring specialists.

Looking forward to upgrade over the weekend.

Have had my RPi on Debian since Debian 9, with smooth upgrades every time.

I have recently migrated ~8y of Apple Numbers spreadsheets (an annoyingly non-portable format) to plaintext accounting.

It took me many hours and a few backtracks to get to a point where I am satisfied with it, and where errors are caught early. I would just suggest anyone starting now to enable --strict --pedantic on ledger-cli from the day 1, and writing asserts for your accounts as well e.g. to check that closed accounts don’t get new entries.

I really miss data entry being easier and not as prone to free-form text editing errors (most common are typos on the amount or copying the wrong source/dest account), but I am confident it matches reality much better than my spreadsheets did.

I'm not sure that's what you're implying, but DNS-level blocking is not more powerful than filtering in the browser, at least in the sense of what it is capable of.

Content-filtering can and most definitely does block domains entirely, but it can also filter page elements served from the same domain which match a known ad "signature".

Though, if you can't run an adblocker, e.g. your Smart TV's browser then sure, DNS-level blocking is your best bet.

I can attest that CSS is very effective for obfuscating e-mail. I displayed my academic e-mail on my webpage for over half a decade using CSS to flip the text direction[1] without getting significant spam.

[1] https://superuser.com/a/235965

I’m not saying this is good security hygiene, but not necessarily everyone with access to the file will also have access to the password in the email.

e.g. someone downloaded the password protected zip on a public computer, logged out of their email, but forgot to delete the file.

I was pleasantly surprised to try the guide out and see that it just worked:

    λ uv venv && uv pip install torch --torch-backend=auto
    λ uv run python -c 'import torch; print(torch.cuda.is_available())'
    True

This is on Debian stable, and I don't remember doing any special setup other than installing the proprietary nvidia driver.

Even if I know my current branch, having my prompt show me untracked/uncommitted/unpushed changes helps to identify if something didn’t work because I’m in a dirty state, or if something I ran (unexpectedly) caused a dirty state.

For example, I don’t expect running scripts/build.sh to modify tracked files in the repo. Seeing part of the prompt go from “” to “?2!3” (two untracked, three changed files) makes that glaringly obvious.

If your pyproject.toml does not list all your dependencies (including dependencies of your dependencies) and a fixed version for each, you may get different versions of the dependencies in future installs.

A lock file ensures all installations resolve the same versions, and the environment doesn’t differ simply because installations were made on different dates. Which is usually what you want for an application running in production.

I have a very involved `gq` alias that helps me find and finish pending work. It works either in the current repository or a folder containing multiple repositories.

Basically, my assumption is that `gq` should return empty, which means I have a clean slate, and can start taking on new work. Otherwise, there is ongoing work that needs attention.

It just lists:

  * modified/untracked files
  * stashed changes
  * local-only branches (not tracking a remote branch)
  * branches out-of-sync with their upstream (either ahead or behind)
  * branches that aren't the main branch (even if tracking and in-sync with a remote upstream)

Getting this command to return empty is a surprisingly effective way to stay productive, especially when losing focus due to too much work.

It's basically inbox-zero for git.

But it only works if you like working with a clean worktree.

One thing I really appreciate about Vim is that it just opens. And I don't mean speed, I mean not getting bunch of pop-ups nagging me to do something about a configuration, extension, feedback or whatever.

I'm not going to claim Vim's defaults are usable for most people, but my god can these IDEs just shut up and let me see my code? I'll go to the settings if I want to.

I agree story has holes but regarding

> The guy who wasn't actually going to work on the issue decided the time estimate of the bug, and then expected the guy who actually worked on the issue to stick to it?

I think he meant that if the ticket was dismissed in a much shorter time than the allotted then it also needs a good reason.

I also believe a bug ticket saying “this shouldn’t happen” is not solved until until “this” no longer happens or everyone involved agrees that it’s okay for it to happen.

And the martial art is jiu-jitsu, not jujutsu. Similar sounding but definitely not “named after”.

Re: continuing a partial rebase

I haven’t tried it myself, but since you know commits A and B have already been rebased and had their conflicts resolved, can’t you instead rebase -i on top of the partial-rebase branch and then drop A and B?

I think this way at least you still benefit from the rebase --edit-todo, which you do not when cherry-picking C^..F.

Was it perhaps a demo of a js plotting library?

https://leeoniya.github.io/uPlot/demos/index.html

And also that 1 copy is (eventually) 0 copies.

Many responses suggesting a simple bash script instead. One reason I like make is that I can just tab-autocomplete targets. No extra setup needed.

If you’re using a single entry point script (e.g. do.sh) and handling $1 you don’t get that for free.

And the moment you need to make your entry point script aware of “B requires A” then you’re going to half-bake something similar to make, anyway.

Here’s [1] my ~80 line version for Python projects (micromamba + uv) which I’ve been pretty happy with.

[1] https://github.com/giovannipcarvalho/micromamba.mk

Huh, I’m pretty sure the version I use is the one from the post and it does have diacritics. (I’m not on my computer now but will check later.)

One thing that bothers me, though, is that “í” is oddly positioned and almost makes it look like there’s an extra space between it and the following character.

There’s fzf-git.sh [1], which is a collection of bindings to invoke fzf for things like branches, commits, tags, etc. I use it pretty often.

[1] https://github.com/junegunn/fzf-git.sh

I think it’s widely accepted that refactors should not change behavior. That’s my experience, at least.

> "Specific revisions should be documented, but documentation should not be limited to a specific revision."

I think this boils down to “what do you do if you realize the documentation for v1.1 says that some feature does X when it actually does Y, but you’re already on version 2.2?”

If v1.1 docs are tied to the version tag in VCS, that incorrect statement cannot be fixed.

And it seems that fixing that forces you into backporting documentation even if you don’t release and maintain parallel versions of your software, which… kinda sucks.

To be honest, I much prefer docs in the repo, because it facilitates code review — a good patch touches some implementation, some tests, and some docs.

The downside when only the latest few versions of the software are supported and only the very latest docs are maintained is that historical docs will probably not be fixed.