> Before you spend many thousands of dollars on a machine better suited to a coffee shop, consider getting a minimalist lever machine.
Agreed. I have a Pavoni Europiccola, and it's made approximately ~11,000 espresso shots (about half of those ended up as milk-based beverages). It makes excellent coffee, and I live in a place where there are a _lot_ of good coffee places around to compare to.
The maintenance is something I do myself, with a few small & inexpensive tools, and a few gaskets I need to replace. The machine will likely outlive me, which is a rare thing to say these days.
If you go back further than that, teams used to destroy entire engines for a single qualifying.
The BMW turbocharged M12/M13 that was used in the mid-eighties put out about 1,400 horsepower at 60 PSI of boost pressure, but it may have been even more than that because there was no dyno at the time capable of testing it.
They would literally weld the wastegate shut for qualifying, and it would last for about 2-3 laps: outlap, possibly warmup lap, qualifying time lap, inlap.
After which the engine was basically unusable, and so they'd put in a new one for the race.
> Don't use the term "hunt" in the name, to me it just screams "dupe" instead of something unique.
> [...]
> You can have "have you launched yet?", "find the next best thing", "what's trending today"...etc
OP: I may or may not be in possession of hasitlaunched dot com, should you be interested in purchasing it…
> The only time exponential backoff is useful is if the failure is due to a rate limit and you specifically need a mechanism to reduce the rate at which you are attempting to use it.
That's what you should be using exponential backoff for. In actuality, the new latency introduced by the backoff should be maintained for some time even after a successful request has been received, and gradually over time the interval reduced.
> I much prefer setting a fixed time period to wait between retries (would you call that linear backoff? no backoff?)
I've heard it referred to as truncated exponential backoff.
This place has both changed a _lot_ and also very little, depending on which axis you want to analyze. One thing that has been pretty consistent, however, is the rather minimal amount of trolls/bots. There are some surges from time to time, but they really don't last that long.
> Er, not really. Not meaningfully. They can be freely compared with timezone-aware timestamps
Author here. My original post was a little ambiguous on this topic; I've updated it to make it clearer.
The tl;dr is that in Python, `time.time()` calls the c stdlib `time` function (at least in CPython), which follows the POSIX standard. It turns out that POSIX standard does _not_ mention timezones at all: https://pubs.opengroup.org/onlinepubs/9699919799/functions/t...
To wit, you can't actually assume that timestamps are UTC in Python, which is a different kind of insanity:
I admit that I didn't fully explain the danger, because I thought it was somewhat self-evident: if you attempt to compare two datetimes correctly, you must know their timezones. Anyone who has used Google Calendar to schedule a meeting in SF when they live in NYC can attest to that.
> You only need a timezone if there was some kind of locality to the event (e.g.: when _and_ where this happened), but usually you can convert to local time. So storing UTC time is fine, adding the timezone in rare cases.
We're both saying the same thing, here.
While UTC is not _technically_ a timezone, most databases/programming languages/etc. let you attach UTC to a datetime. When you say that you're "storing UTC time", you are implicitly storing it with enough information.
The difference is that I don't like the implicit nature of assuming a timezone-naive datetime is UTC, because that is a very dangerous assumption to make. Just store the timezone, even if it's UTC!
I thought the same, and went from an Apple standard keyboard to a Moonlander. Some time after that I went to a custom 36-key split ergo board.
It takes a little time to familiarize yourself, but you get very proficient with layers and home-row mods. The main benefit is that every single one of my fingers never has to move more than one key in any direction, and it has markedly improved my wrist health.
Is the `FOR UPDATE SKIP LOCKED` in the CTE necessary? Granted my understanding of Postgres row-level locking and their interaction with CTEs may be a bit lacking, but according to the docs[1]:
The sub-statements in WITH are executed concurrently with each other and with the main query. Therefore, when using data-modifying statements in WITH, the order in which the specified updates actually happen is unpredictable. All the statements are executed with the same snapshot (see Chapter 13), so they cannot “see” one another's effects on the target tables.