xoudini

> 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.

[1]: https://docs.djangoproject.com/en/4.1/ref/models/fields/#enu...

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.

[0]: https://www.researchgate.net/publication/328738331

Link to anchor: https://www.spacex.com/updates/index.html#sl-geostrom (sic)

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].

[0]: https://www.haveibeenexpired.com/ssl?q=colasloth.com

[1]: https://crt.sh/?id=5909251719

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.

I'm not familiar with the software in question, but I'm quite sure it'd still be possible to have someone else to sit your exam. For instance, you could have an external webcam pointed at yourself, and have someone else in front of your computer writing the actual exam. Maybe even mirror the display so that you can see what your accomplice is doing.

Here's a (perhaps "unnecessarily clever") Python 3 version I wrote a while back, for some reason:

    import functools
    
    def fizzbuzz(n):
        if not n % 3: yield (r := "fizz")
        if not n % 5: yield (r := "buzz")
        if not "r" in locals(): yield n
    
    compose = lambda f, g: lambda *args: f(g(*args))
    functions = "".join, functools.partial(map, str), fizzbuzz
    transform = functools.reduce(compose, functions)
    print("\n".join(map(transform, range(1, 100))))

I can see this happening, but with a reasonable bug-tracking solution in place and enforcing `fix/...` branches for fixes, these situations could mostly be avoided.

Hm, you're right. The simplest example I could think of right now is the upstream having renamed/deleted something that the dev branch depends on, but didn't directly touch. That would definitely cause a "broken" history during the rebased commits, and is technically unavoidable.

In some cases I agree, but squashes can end up so large that doing a `git bisect` (which is quite useful in finding the comparatively small commit which introduced a bug) becomes unfeasible.

When you rebase, you basically replay the history of your branch since it diverged from the branch you're rebasing onto. Thus, the branch is always in a consistent state (or equally consistent to when you originally authored the commit you're replaying). And of course this assumes the target branch is already in a consistent state.

There shouldn't be an issue in doing so. During a rebase you'll either have no conflicts — in which case there isn't an issue — or you'll have to stop to resolve conflicts, and you might as well run tests before continuing the rebase. In both cases I'd argue that the statement "coherent set of atomic changes" applies.

In Swift 3 (and probably previous versions as well), `String.count` defaulted to the count of the Unicode scalar representation. In this version, iterating over a string would operate on each Unicode scalar, which often doesn't make sense due to the expected behaviour of extended grapheme clusters. So, this is my best guess why `String` in Swift 4 and later ended up with the current default behaviour.

I had a similar thought:

  git init -q && git commit -q --allow-empty -m "Hello, World\!" && git show --format=%B | head -1