HN user

operator-name

1,084 karma
Posts6
Comments370
View on HN
Turn Dependabot off 5 months ago

The custom Github Actions approach is very customisable and flexible. In theory you could make and even auto approve bumps.

If you want something more structured, I’ve been playing with and can recommend Renovate (no affiliation). Renovate supports far more ecosystems, has a better community and customisation.

Having tried it I can’t believe how relatively poor Dependabot, the default tool is something we put up with by default. Take something simple like multi layer dockerfiles. This has been a docker features for a while now, yet it’s still silently unsupported by dependabot!

I'm not sold at the idea - for most projects it makes sense that the author of the PR should ultimately have ownership in the code that they're submitting. It doesn't matter if that's AI generated, generated with the help of other humans or typed up by a monkey.

A computer can never be held accountable, therefore a computer must never make a management decision. - IBM Training Manual, 1979

Splitting out AI into it's own entity invites a word of issues, AI cannot take ownership of the bugs it writes or the responsibility for the code to be good. That lies up to the human "co-author", if you want to use that phrase.

a PC laptop with Apple build quality and display quality, and there definitely aren't many options

There’s been a bunch of Windows ARM laptops that aim to directly compete with the M series Macs. Linux compatibility will depend on make on model.

From reading this thread I’m glad I’m not alone. It seems their “compact” mode has a bunch of invisible gestures that you’re just supposed to know about.

Luckily I’ve also discovered that you can revert back to “bottom” tab mode in the settings, which brings back something similar to the old UI.

As a long time Android user, I find these magical gestures frustrating difficult to discover. How on earth is someone supposed to guess such a gesture exists, and how am I supposed to guess the rules for when certain gestures work and certain gestures don’t?

Even long time friends who are iOS fanatics, and who have used iOS since the beginning are often surprised when I show them a new gesture I’ve learnt. Am I missing something? I’m really grateful to learn this now but I can’t imagine the “Apple way” is to stumble upon these by forum comments?

I strongly disagree. Making invalid state unrepresentable is important.

wastes space premature optimisation

A timestamp is a witness of when the email was verified. Since if they’ve verified can be calculated from it, having both is not only redundant but allow invalid states to be represented.

Cases like email verified are often followed by the need to know when. Say an expiry system. Going from bools, you are faced with the hard choice of how to migrate existing state.

Databases also warrant more care as a source of persistent state - accessed by multiple versions of your software. If you don’t have this persistency, then it matters less.

any other fields that happen to be strings or numbers or blobs were changed implement proper event logging

Event logging is orthogonal to your database state. If your business logic needs dirty flags or timestamps they should be stored in the database, not queried.

And if you do need it for other fields, adding the bool is the perfect time to ask yourself if what you need is a timestamp.

way we don't start with floats rather than ints "just in case" we need fractional values later on

Floats are a subset of int, and a natural migration. A bool can be calculated from a timestamp, but not the other way.

Certainly an interesting approach compared to asgiref or synchronicity but I have doubts about the approach.

Does this not add further function colors - that of a transfunction, tiddle superfunction and non-tilde superfunction? Now every time you call one from another you need to use both the context managers and know what variant you are calling.

asgiref provides the simple wrappers sync_to_async() and async_to_aync(). Easy to understand and to slowly transition. Caveat is the performance impact if overused.

synchronicity uses a different approach - write 100% async code and expose both a sync and async interface. async def foo() becomes def foo() and async def foo.aio().

https://github.com/django/asgiref https://github.com/modal-labs/synchronicity

If Android was anything to go by, migrating build systems is a risky endeavour. Miso claims compatibility with ninja, so I’m guessing this route was deemed easier to make incremental improvements.