New Zealander here, really thrilled to see our national medical testing service (primarily blood tests) in here. I've sent a note to them to make sure they're aware of this.
Also I feel like I took the wrong path, trying to be a serious and responsible software developer - seems like all the money is in throwing shit together and making wild claims about it.
For events that have happened, absolutely. Events in the future are often slightly more ambiguous though!
I do agree that "with attached Timezone" or "as UTC" are absolutely the sensible defaults, I'm just suggesting that sometimes "plain" datetimes are semantically the correct choice.
For sure, but for future events to be correct I still have to store that as (plain datetime, pacific/auckland), not translated to utc at the point of creation/saving. If I store only a UTC datetime I have unrecoverable lost important information.
Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England.
I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a location - "this event happens at 9am according to whatever timezone is currently in effect in Auckland, NZ". That's a thing that UTC or timezone-aware Datetimes can't help with.
I'm a some-time Django developer and... I caught the bug instantly. Once I saw it was model/ORM code it was the first thing I looked for.
I say that not to brag because (a) default args is a known python footgun area already and (b) I'd hope most developers with any real Django or SQLAlchemy experience would have caught this pretty quick. I guess I'm just suggesting that maybe domain experience is actually worth something?
Natron is essentially a clone of Nuke, the ~standard compositing software for the VFX industry. It's impressive that it exists and competes with some very expensive alternatives.
Its maths and colour science is good and it seems to operate correctly on images. Unfortunately usability and performance are pretty weak. I've managed to replace Nuke or Resolve with it for the parts of my workflow that are colour conversions from e.g. ACEScg to sRGB, or for encoding videos (it wraps ffmpeg), but I'd hesitate to use it for anything creative and it definitely doesn't approach the animation facilities of After Effects.
I've only played with Nim a little, but I found it really compelling and honestly quite fun to write. It's quite elegant and economical and the performance is impressive for the lack of ceremony.
However, the language itself still seems to be a little in flux (v2.0 is nearly out, and my impression is that v3.0 might finally be a nice stable language) and the BDFL makes some language decisions (and holds some opinions) that I'm not fully on board with, and I think make the language a little less than it could be. Obviously that's subjective though.
I'll definitely keep an eye on it and check back in periodically, but I'm also not going to write any non-disposable code in it for now.
NZ isn't currently issuing visas outside of a few categories of "special worker in shortage". (In order to citizens and residents a better chance at getting a quarantine spot.) So this introduces a new special exception for the very wealthy.
He's pretty clear in the article that it's the "title-description-body" model that doesn't work -- tweets don't generally benefit from a title or a summary.
In the VFX industry you don't roundtrip lossy codecs; first step is to decode to something lossless like EXR or TIFF, and those are what you pipe through your workflows. (With maybe lowres JPEG "proxies" to make iteration a bit quicker.)
Film/TV more generally I think tolerates slightly lossy codecs like RED or Pro Res, as there's often only 1-2 intermediate steps that could cause extra loss. (E.g. the part of editing that is just 'cutting' is pass-through, but color-grading would require a second encoding step.)
It's essentially the same process to begin with (I think), but every time the ray hits something you fire off secondary rays probabilistically from the hit point to see what that point is receiving light from, and so on ad infinitum. Usually you're calculating a BSDF[1] for each surface you hit, which tells you where to cast your next set of rays.
The point is that you're not expecting people to ever pay it, because you've set it high enough to be a solid disincentive. If people are actually paying it regularly, you obviously haven't set it high enough.
This is also common when quoting freelance projects you don't really want to do.
I use Podman on both macos and Windows, with compose files, so I'm a bit perplexed by this whole comment.