I wonder if the author considered moving payment processing to Adyen from Stripe? They're also EU-based and a bit more... well known? I liked integrating with them in the past.
IMO one of the cool things about Wallet is the notification that appears on the homescreen when you're in proximity of the venue or time of the event and automatically displays the pass when tapped. I wonder if "create your own" will be able to do that (I'm not sure how it would)?
For one, the article doesn't suggest that this will indeed be allowed as a part of that process. OTOH: it's easy for a flight ticket pass (which has time and airport location) but not for a gym membership pass (time can be anything and the gym can have several locations.)
Location-based functionality like this is already widespread in iOS; I'd be surprised if it wasn't supported. Reminders and calendar events (and PassKit!) already have it, for example.
I said this elsewhere in the comments, but I think there's sort of a fundamental tension that shows up sometimes between DRY and "a function/class should only do one thing." E.g., there might be two places in your code that do almost identical things, so there's a temptation to say "I know! I'll make a common function, I'll just need to add a flag/extra argument..." and if you keep doing that you end up with messy "DRY" functions with tons of conditional logic that tries to do too much.
Yeah there are ways to avoid this and you need to strike balances, but sometimes you have to be careful and resist the temptation to DRY everything up 'cuz you might just make it brittler (pun intended).
I think there is often tension between DRY and "thing should do only one thing." E.g., I've found myself guilty of DRYing up a function, but the use is slightly different in a couple places, so... I know, I'll just add a flag/additional function argument. And you keep doing that and soon you have a messed up function with lots of conditional logic.
The key is to avoid the temptation to DRY when things are only slightly different and find a balance between reuse and "one function/class should only do one thing."
For sure. I feel I need all of my experience to discern the difference between “slightly different, and should be combined” and “slightly different, and you’ll regret it if you combine them.”
One of my favorite things as a software engineer is when you see the third example of a thing, it shows you the problem from a different angle, and you can finally see the perfect abstraction that was hiding there the whole time.
Yeah - I think it still a bit of a deterrent ... today, not everyone has a camera, and if I were a thief and one house had cameras while the place next door did not, guess which one I'm gonna rob?
But I wonder how much of that will wear off once everybody has one.
> A thief doesn't know if there's a doorbell camera on a particular home until they're already on the porch and recorded.
When a thief wants to steal something, they usually stop trying to steal that thing once they become aware they are being monitored. Even if they only realized once they reached the porch.
It's not a guarantee, but it's something. And it provides a trail to follow if something is stolen (or worse).
I understand your skepticism 100%, but I suspect you might change your mind if you, say, rented a car with it for a week. It's definitely a net positive for safety, and it probably costs the auto maker less than the seat belts (literally).
I've owned cars with backup cameras since about 2014. I still mostly back up the old fashioned way, and really only use the camera for very tight situations where a few inches matter.
ive owned two cars. the modern backup camera means the new one has small "stylish...." rear windows. it is wayyyy more dangerous than the older one with no sensors
i only have those two data points; but give me an older car with larger windows every. single. time.
reply