jperras

18 year HN vet here. I've forgotten most of these, even though I was around for nearly every single one of them!

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.

This is just… event sourcing?

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

There's also /classic, which only counts votes from user accounts created before a certain cutoff date.

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

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.

The reviews are on the Scotch site itself, not on Amazon: https://www.scotchbrand.com/3M/en_US/p/d/cbgnhw011057/

Sorry, the reviews are actually on the Scotch site itself: https://www.scotchbrand.com/3M/en_US/p/d/cbgnhw011057/

Those scissors apparently have a habit of the handle melting away (see reviews): https://www.amazon.com/dp/B00SSVNNZC

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

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.

16 year HN vet here.

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.

Very fair. The line between conscientious preservation and alienation can be (and often is) an easy one to cross.

Québecois here. We've been trying to tell the rest of Canada this for _decades_.

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:

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

differs materially from

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

Author here.

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.

Instead of trying to tax the people into complying with your desires, make them want to do so of their own free will!

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

Ah, I see - the default transactional isolation level is what I wasn't accounting for.

Thanks for the explanation! Very much appreciated.

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.

Lifelong Montréaler here. I think having "problem" in the title is what is ruffling feathers, although I'm not particularly bothered by it. That's perhaps where the analogy is strained the most: stylistic divergence in code can be problematic, but in architecture and urbanism it's typically seen as an asset.

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

Humans have always had a tendency to develop a deep understanding of their tools, and even to refine them to better suit their needs.

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.

Montréaler here. A surprising amount of people cycle all winter long; the days where you see no one cycling about are typically days where you wouldn't even want to be outside in a car due to the inclement weather.

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.

Counterpoint: I live in Montréal, and the city tracks cycling usage via (infrared?) counters on major bike paths.

Last year there were 1.5 _million_ trips on a single section of a dedicated cycling path that runs through a very commercial part of town. We have so much bike traffic that there are bike-only traffic jams and long queues at stop lights (again, all on the dedicated/separated bike path). And you better believe that a lot of people shop on their bikes, myself included.

As charcircuit figured out, the username is/was `malware`. They deactivated it in 2018 without any explanation, and even my contacts at Github at the time couldn't quite figure out why it was happening.

My only thought was that it was during the MSFT acquisition due diligence, and my username was an unfortunate victim of whatever compliance requirements they had to satisfy.

I've actually had a (great) username completely blackholed by github. I'm still a bit salty about it.

I had received an email several years ago informing me that it was going to be removed. They gave me the equivalent to a coupon for a free year of the github personal plan as compensation.

To this day it'll tell you that the username is "unavailable" if you try to sign up with it, and the page just 404s.

Canadian here. Sadly, it's common practice around these parts for buyer agents to completely ignore listings that don't have a selling agent attached; it's their form of industry protectionism.

As a result you end up losing out on a large surface area of buyers who rely on their buying agent to find properties, which puts you at a disadvantage.

Thank you for the thoughtful reply. I'm not very well versed in this domain, and it's nice to have a civil discussion about wearable tech, especially when previous implementations have instantly become vapourware.

So yes a phone can do all that, and it ALSO would be awesome, but just like with these glasses you can't ACTUALLY implement this.

A perfect summary, I think!

The cognitive load of the notifications is an interesting point that I hadn't considered; I can see myself being distracted by those in the workflow I proposed in my previous comment.

I wonder if much of this could be solved by OS-level functionality (or at least having it in a developer-accessible SDK) that allows the new "always-on" lock screens to immediately trigger an application on a single tap.

Imagine if you could take a picture of anything, add a little note, have it filed away. Not necessarily an awesome Instagram picture, but just a picture of some mail you got, a tool you are putting away, any thing you want to record and save. Heck, why not a picture of your computer screen? Pair that with quickly available audio transcriptions and you can also dictate anything, thoughts, small notes, information associated with the images.

I know HN already has too much cynicism for my own liking, so it pains me to say: you can already do this with the phone you have in your pocket. Have a shortcut that enables audio dictation/photo mode/etc., and you're good to go.

The workflow for glasses (either these or some other hypothetical ones) would involve hitting a button and then having to either speak the command out loud or hit some other button to capture video/audio/etc., which seems more cumbersome than the phone approach that exists today.

Love seeing more visibility for the NFB.

My favourite of theirs is a short documentary on Doug Rogers, the first Canadian to win a medal at the Olympics in judo.

https://www.nfb.ca/film/judoka/