purerandomness

Why not simply use NewPipe [0]?

You also get ad filtering and you can download Audio/Video streams from within the app.

[0] https://newpipe.net/

In PHP, an established tool is adding GrumPHP [0] to your dependencies.

It will then handle git hooks on each commit via composer script by default (but can be omitted per commit).

[0] https://github.com/phpro/grumphp

IPv6 will never make it. Maybe IPv8 [0], which IPv6 should have actually looked like:

> 1.1.1.1.1.1.1.1

[0] https://www.ietf.org/archive/id/draft-thain-ipv8-00.html

FastAPI is quite old (2018)

Svelte even older (2016, SvelteKit was just an new version in 2022)

SQLAlchemy is ancient (2006)

Use newer tech, like HTMX (2020)

(/s obviously)

MySQL does not let you have transactional DDL statements (alter, create, index etc).

If you're building anything serious and your data integrity is important, use Postgres.

Postgres is much stricter, and always was. MySQL tried to introduce several strict modes to mitigate the problems that they had, but I would always recommend to use Postgres.

Exactly. That's my point.

When saving, it simply should say "Exporting pic.jpg".

If you want to draw circles, you're probably looking for a vector drawing program, like Inkscape.

If you want to draw squares, you're probably looking for a vector drawing program, like Inkscape.

Why is then opening a JPEG not an Import?

I get it, and when Photoshop changed this default, GIMP followed with changing this workflow. It used to be different in older versions of Photoshop and Gimp.

Advanced user usually know exactly what they're doing, and opening a PNG or JPEG file, changing a few pixels, and saving it, should require as few key presses as possible.

I don't want the UI to get in my way when I open->edit->save.

k9s, ncdu, htop, powertop are good showcases how a TUI reduces mental load and are superior to browsers and / or other GUI tools

You haven't been around here in the Blockchain/NFT/Smart Contract dark ages, have you?

> keep trying because really deep down they just don't know how nice you're being by giving them a chance to talk to you.

I don't fathom what kind of trauma would lead you to take this positive, light-hearted advice to connect to fellow human beings, and to spin this into such a vile, evil, anti-social narrative.

How does that help?

I think you misunderstand what the XKCD comic implies.

It's been around as long as TUI tools have been around (Midnight Commander, etc)

Here's a blog post from 2014 [1] mentioning it.

Sometimes, we're the one in today's 10000, sometimes it's someone else [2]

[1] https://khanifnasrudin.blogspot.com/2014/11/text-based-user-... [2] https://xkcd.com/1053/

> "not just X; it's Y"

...is a typical tell-tale cadence in the current breed of LLMs.

The tell-tale signs change over time, but this one is very obvious.

You might like https://www.lazarus-ide.org/

brew is for users of non-Arch distros who want to experience what using Arch feels like.

So why did you poke the bear then, by handing out cookies during the Euromaidan and starting the US-Russia proxy war that is fought in Ukraine right now?

Btw, sorry we can't help you with your little Venezuela "war" right now, we're on winter vacation; your E-mail will not be forwarded.

Fair enough, you do you.

Meanwhile, we'll be protecting your loved ones.

What's the point of declaring war in a war?

Russia invaded Ukraine just fine without ever declaring war.

The reality of React is that you have to keep re-learning and un-learning stuff if you want to keep up with React's ecosystem, because the surface area of the libraries is so large. (see "JavaScript fatigue")

Whereas with HTMX you learn a very, very basic concept in 15mins, and you're good to go for the next decade(s), and it will be more than enough for 80% of your projects.

Same as with vim and Emacs vs. proprietary IDEs and text editors.

> We're very close to invokers being baseline

Well why not have the benefits of invokers, but today - with HTMX?

HTMX could eventually switch its implementation to use invokers under the hood in the future, and you'd have the convenience of using declarative behaviors on your buttons, today.

> autocomplete can actually be fulfilled with a datalist element

I wish that the spec would cover more use cases, but last time I tried to use it, I couldn't, because it has really bad UX, and is inconsistent across browsers.

Also, like you mentioned, it only works for small data sets that you can deliver with the initial HTML, not large amounts of data which reside on the server.

You could argue that these are use cases where you wouldn't require an auto-complete in the first place, because the data set is too small.

> If your solution is actually good, it will get adopted eventually...

I wish this were true.

Unfortunately, often the things that get adopted are the things hyped up the most, not the ones which are technically superior.

Popularity, marketing budgets and inertia often dictate what's popular.

As with all biases, we need to actively and deliberately work against these forces, if we value craftsmanship and professionalism.

Please install a TLS certificate to the site so people can view the content.

Reminds me of "Falsehoods programmers believe about addresses" [0]

[0] https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...

It's always a skill issue.

Guard rails should be there to prevent inexperienced developers (or overworked, tired ones) from committing bad code.

"Try to think how to refactor functions into smaller ones and give them meaningful names so that everyone knows immediately what's going on" is a good enough guard rail.

The blueprint is the code.

> "comment brevity, and try thinking of a clearer way to do something instead of documenting the potentially unnecessary complexity with a comment"

That's exactly what I wrote, phrased slightly differently.

We both agree at the core.

Avoiding comments is an exercise in thinking how to rename or refactor a function, or a variable in such a way that a junior developer will be able to read it like prose, and immediately understand what's going on.

It's cognitively stressing, but is beneficial for juniors, and developers new to the codebase, just as it is for senior developers to reduce the mental overhead for the reader.

It's always good to spend an extra minute thinking how to avoid a comment.

Of course there are exceptions, but the mental exercise trying to avoid having that exception is always worth it.

Comments are instant technical debt.

Especially junior developers will be extremely confused and slowed down by having to read both, the comment, and then the code, which was refactored in the meantime and does the opposite of what the comment said.

Why should each one of your clients reimplement the calculated value, each in a slightly different way?