https://martinfowler.com/eaaDev/EventSourcing.html

The cutoff used to be early 2008, I believe, but that may have changed in the last ~17 years :)

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.

As one comment pointed out, they could be using nitrocellulose in the handle.

OP: I may or may not be in possession of hasitlaunched dot com, should you be interested in purchasing 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.

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:

``` datetime.datetime.utcnow().replace(tzinfo=pytz.timezone("America/Toronto")).timestamp() ```

differs materially from

``` datetime.datetime.utcnow().timestamp() ```

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!

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.

… do you have any idea of the costs that are associated with owning and operating a vehicle in Tokyo?

Thanks for the explanation! Very much appreciated.

  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.

Perhaps calling it the "Montréal effect" would be more apropos?

Many people in North America use a microwave every day. Does that mean they have or want a deep understanding of magnetrons? Likely not. Of course, this is because microwaves generally just work as expected. But I can't imagine a scenario where microwave home repair would be a thing that people would be okay with if they were unreliable.

Winter cycling is actually popular enough that our bike-share system has started to leave a portion of the sharing infrastructure out during the colder months. They put studded tires on the bikes, put the stations in locations where they aren't in the way of snow plows and the like, and people use them quite a bit! Something like 1,500-5,000 rides per day, just in the shared infrastructure. That doesn't count the even larger number of people here who have their own dedicated winter bike.