Do you specifically go out of your way to check who sent every transactional email you receive and take notes on which email sending service your order confirmation was sent by? That would be a very weird thing to do and would be the only way to know that.
The physical card is explicitly just a backup option for when contactless payment isn't available. It would be sort of weird to make it support contactless payment.
I use and love Apple Pay, but it's not ideal for every situation. The biggest flaw is that it requires waving your expensive phone in the vicinity of the reader.
Apple Pay is more risky than contactless cards. There is a risk of dropping your phone or it being stolen out of your hand. I only use it in controlled indoor environments, like at a retail store, where I have enough personal space to feel comfortable getting out my phone. If I want to pay at e.g. a stall in a crowded market, I'm using my card.
EDIT: hmm, actually the screenshots on Apple.com show a card with a chip, so how come contactless doesn’t work? Deliberately disabled?
—-
Wearing my ecology hat, you could argue if barely any of their customers will use it for contactless, then it’s a waste of resources manufacturing a chip.
(Of course there are plenty of other areas of Apple’s business where they thoroughly undermine this - persuading people to buy wireless in-ear headphones, iPads that have so much glue inside when you ‘replace’ the battery they just give you a new device because it’s too much hassle etc.)
Or… maybe insisting on using Titanium means it’s an PITA adding a chip as well, versus plastic? (At least one of my UK cards claims “made from 100% recycled plastic” now).
One byte equals one character was already incorrect in the pre-unicode days for east asian languages. UTF-8 is much easier to parse than something like Shift JIS, where splitting a string in between bytes of a codepoint results in a valid but incorrect string.
I can't get a $10k workstation but if I used $10k/month on cloud compute it'd take a few months for anyone to talk to me about it and as long as I was actually using it for work purposes I wouldn't run into any consequences more severe than being told to knock it off if I couldn't convince people it was worth the cost.
It is very common for there to be "accept all" and "more options" buttons where rejecting all requires multiple clicks via the latter. The sites which havea "Reject all" button right next to the "Accept all" one that's the same size and such aren't flagrantly violating the law.
2-5x faster than both abseil's b+tree and std::map means that abseil's b+tree had to be the same performance as std::map for the tested workload. This is... very unusual. I have only ever seen it be much faster or moderately slower.
Not necessarily. Insert could be 5x faster in one, and 2x faster in another, and there would still be orders of magnitude difference between both. 2x-5x is a long range.
The idea that you pay the interest up front is a very common misunderstanding of how mortgages work and more broadly the concept of an amortization schedule.
Yeah, I see people describe it like that all the time, it's never corrected, and doesn't match how I always thought mortgages in general work (and definitely doesn't match mine), so I'm never entirely sure if it's a different system from another country or just a version of the blind leading the blind. Which is why I made my comment so specific to myself.
The parent of that comment mentioning "a fee to overpay" is one I've never even heard of before. Definitely not the case here, free to pay down the principal as much as I want whenever I want as long as the current interest for the month is paid first.
My experience with the ruby ecosystem has been that if you get everything set up correctly all of the environment management tools have worked wonderfully. When you don't have everything set up correctly, they break in ways that is hard to understand for someone not intimately familiar with the ecosystem. It's something that's not at all a problem for someone using ruby as their primary language, and a major source of pain for dabblers and people who just want to run something written in ruby.
That's a fair point. That's why I'm interested to know what is at the core of AlphaSite's complaint.
One challenge, as I see it, is that there are three kinds of Ruby projects that need to take different approaches to the matter, in increasing level of complexity:
(1) Developing a longer-lived, deployed or distributed project. Here you should definitely use both the Gemfile Ruby version and a .ruby-version file. You're normally only targeting one version at a time, but contributors and/or users are very unlikely to somehow accidentally end up using the wrong Ruby version without getting a very obvious notification that they are using the wrong Ruby version. That's annoying to encounter, but not difficult to solve once you know that the concept of a "version manager" exists.
(2) Hacking on your own small project or just banging out a script. You just want to run some Ruby version and get to it. You probably should default to the latest, unless there's some dependency requiring a lower version, and you might not know that until after you've gotten started. The inverse issue might also occur, e.g. you installed Ruby 3.1 a few years ago, you start hacking, and now you want to pull in a gem version that requires Ruby 3.4. You can manage this by putting the Ruby version in your Gemfile, or using a .ruby-version file, or both, but if you're relatively green and just diving in, this might not be on your radar.
(3) Developing a gem. You probably want to test/validate your gem across multiple Ruby versions, and possibly even different versions of your dependencies. You obviously don't want to lock yourself into a single Ruby version, and use of a .ruby-version file is inappropriate. There is tooling to do this, but it takes some learning to be able to utilize.
My belief is that it is worth it for install documentation for category (1) to be a little more explicit about how to get up and running. For category (2), I don't know what the right answer is, but I understand the potential pain points.
What I was most curious about is whether AlphaSite's complaint was with a specific version manager, or the fact that multiple options for version managers exist, or even the need for version managers at all?
For a long time I avoided projects written in Python for this same reason, though they seem to have resolved the issues over time. The only stack these days that gives me pause is nodejs, but for different reasons.
