I'm not sure why the article picks these 3 options as if that's it.
An RPC API can happily exist over plain old HTTP/1 (no protobuf required) and it also doesn't mention the primary benefit of RPC over REST/RESTish (IMO) - and that's the ability to stack multiple RPC calls into a single request.
De-anonymization would take monitoring over a period of time, but it could definitely work. Take this scenario for example: a person of interest is in the area of New York on Jan 1. On Jan 4 they travel to the UK. On Jan 7 they travel to Germany. On Jan 21 they travel back to the US.
The list of suspects would be fairly small when US officials cross-check individuals that travelled US-UK on Jan 4 and Germany-US on Jan 21.
For the previous 20 years I had no real routine other than wake>commute>work or wake>work if wfh, but over the last 2 years I've been more focused on my health. Every weekday I get up around 06:00 and am at the pool by 06:40. I swim 1500m then have a 15min sauna and 4min cold plunge. Normally I'm back at my desk by around 08:20. I drink 1L of water with electrolytes while at the pool and then have a light breakfast and espresso when I get home.
I'm in better shape than I was throughout my 30s, have more muscle, better posture and generally feel more energetic and alert through the day.
While at the pool I listen to Audible books (wearing Shokz), so get through a new book every couple of weeks also.
Automating such a narrow edge-case seems totally pointless. A much more likely scenario is that your battery dies while you're out, in which case you're still screwed.
A better tried-and-tested real world solution that covers all scenarios is a simple key safe.
I suggest this tiny thing named "key" is an appropriate solution. Hard to break through dropping, no battery, the home doesn't need electricity and so on.
While I understand the tinkering here for fun, the author did ignored the actual problem of the drained battery completely?
I shared this elsewhere but I could have expressed the initial problem a little clearer, which actually was "enter my home without unlocking my phone which causes my phone to die in the cold."
Unlocking the screen caused the battery to drop immediately - it still had network connectivity prior to that.
I think the initial problem was clearly-enough stated, and the GP's point is valid - why bother accounting for the case where your phone is so close to dying that you can't unlock the screen, when just a bit less battery life would mean that your phone dies regardless (and you're stuck outside anyways)?
The battery level isn't actually close to dying, in my case it just rapidly depletes from up to 40% when it's very cold. But that 40% remains intact seemingly with the screen off. Could be my phone also, but it has happened often enough that I wanted to solve it and thought this was an interesting approach.
For me, this was just a matter of convenience and not optimizing for most resilient or reliable solution. I do have backup plans for home entry.
Batteries are generally less able to source current when very cold. At low temperatures, the battery was sufficient to power your phone in a low-draw state (minimal network activity, no screen, low power CPU state), but the voltage dropped when current draw increased.
I experienced this. I ran to work at -10F. When I arrived, I took out my phone to take a photo of my ice beard and although it almost immediately died.
It is more common than you think. Turing on the screen in cold weather is usually the thing to make the phone shut off. The solution still saves you the trouble of having to take off your gloves to access your phone.
While the breaking change in a Mongoid minor release is particularly egregious, let's face it - the real failure here is lack of sufficient tests. I would be very surprised if this was the only place they used or() in their app so it should have made their test suite light up like a Christmas tree.
It would be more interesting to see those numbers in square footage and not straight counts. I would expect the majority of the 'empty' homes are the £10M+ ones in Knightsbridge, Chelsea, Kensington etc.
We use wkhtmltopdf on AWS Lambda and have had zero issues in production for the last ~2 years. We're generating internal owned documents (invoices, letters, paged forms, etc) so I wouldn't necessarily trust it with untested input HTML but it really has been bulletproof for our use-case.
At some point we'll likely move to chrome/puppeteer but in most of our tests the templates required modifications to mimic the existing PDFs so it's something we've been putting off.
An RPC API can happily exist over plain old HTTP/1 (no protobuf required) and it also doesn't mention the primary benefit of RPC over REST/RESTish (IMO) - and that's the ability to stack multiple RPC calls into a single request.
reply