> without any external dependencies (i.e. no Redis/RabbitMQ)
You still depend on a database with the `Task` model. This would be a no-go for that reason, since there's no reasonable way to have an impact on its behaviour, outside of creating a custom database router to avoid having every third-party library hitting the same database as core logic.
If you absolutely must use a model, take a look at enumeration types[1] for a slightly "neater" way to declare choices.
I won't comment on whether it's a solved problem in general, as I don't actively follow the area very closely, but that particular QRNG has been shown to be more biased than /dev/urandom [0], and other QRNGs have exhibited similar issues.
Well, just letting it expire would certainly halt local development at <dayjob> until renewing. The primary reason for this is that some integrations require TLS for callbacks, so we have a local reverse proxy serving everything with TLS enabled. Hence, it's just more pragmatic to run the dev environment with TLS enabled all the time: no need to modify configurations and reset the browser cache when moving between a TLS and non-TLS setup.
I do get emails from the CA reminding me to renew a month or so before expiry, and the certificate hasn't been revoked as of yet, but it'd be useful to be alerted regarding the latter, were it to happen.
That would be my exact use-case for a service like this: monitoring a domain I have pointing at localhost (and not only for expiry, but also for revocation). At least currently the demo check fails on trying on trying to establish a connection[0], although a valid certificate definitely exists[1].
Well, to be fair, the `len` operation on lists in Python is a constant time operation. What makes the example particularly bad is using a cast on the result of a floating-point division, rather than just using Python 3 integer division (i.e. the `//` operator). Copilot was clearly just spitting out Python 2 code here.
You still depend on a database with the `Task` model. This would be a no-go for that reason, since there's no reasonable way to have an impact on its behaviour, outside of creating a custom database router to avoid having every third-party library hitting the same database as core logic.
If you absolutely must use a model, take a look at enumeration types[1] for a slightly "neater" way to declare choices.
[1]: https://docs.djangoproject.com/en/4.1/ref/models/fields/#enu...