Back during the real estate frenzy of the late 2010s I would get calls all the time asking how much I would sell my house for. I’d say “I could probably let it go for 2 million dollars.” (Even at the ridiculous peak, it was never worth more than 750k.) There would be a few seconds of silence on the line while they actually looked up my house. Then they’d say “oh.” And hang up as fast as humanly possible.
This is absolutely fundamentally wrong. What you’ve described is what Nodatime calls an Instant, and it’s a very important data class, but there are valid reasons to use other classes.
A LocalDateTime cares about the date and time locally. An event scheduled for 8am every Monday might use this. It would update accordingly if you move locations to a new locale.
A ZonedDateTime can almost be directly translated into an Instant, except that one time zone might change. If you go into or out of daylight saving time, or your region decides to change its time offset. Oslo time is still Oslo time. You use this if your event occurs at a specific time in a specific location.
An OffsetDateTime is like a ZonedDateTime, but instead of being tied to a specific time zone (e.g. “Oslo time”) it’s tied to a specific UTC offset (e.g. UTC+1).
You don’t have to use Nodatime, but you should at least think deeply about what your time objects actually represent and what is the best way to represent them.
I would vote for docker as well. The last time I had to inherit a system that ran on virtual machines, it was quite a pain to figure out how the software was installed, what was where in the file system, and where all the configuration was coming from. Replicating that setup took months of preparation.
By contrast, with Docker, all your setup is documented. The commands that were used to install our software into the virtual machines and were long gone are present right there in the Docker file. And building the code? An even bigger win for Docker. In the VM project, the build environment for the C++ portion of our codebase was configured by about a dozen environment variables, none of which were documented. If it were built in Docker, all the necessary environment variables would have been right there in the build environment. Not to mention the build commands themselves would be there too, whereas with VMs, we would often have developers build locally and then copy it into the VM, which was terrible for reproducibility and onboarding new developers.
That said, this all comes down to execution - a well-managed VM system can easily be much better than a poorly managed Docker system. But in general, I feel that Docker tends to be easier to work with than a VM. While Docker is far from flawless, there are a lot more things that can make life harder with VMs, at least from my experience.
This was a common April Fools prank back in my day. We would put a startup script on a person’s computer that opened their CD drive at random intervals. Drove them nuts!
Have you seen the film Dark Star? Bomb number 20 gets stuck in the release bay with the detonation countdown still running, so they have to spacewalk out and convince the AI not to explode.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.