lol I have another story regarding Apple gift cards.
Many years ago we had an iMac at the house as the shared desktop computer. After a few years, it started to have the signs that the harddisk is going to fail, and also we were mostly moved away from Apple's ecosystem, so we decided to trade it in and replace it with something else that's not from Apple.
Since we don't have anything immediate to buy from Apple, we traded it in with Apple gift cards.
Later, my partner needed to trade in an old iPad for a new one, so we used that gift card with credit card for the trade in. For that trade in, you first pay the full price with gift card+credit card, then they refund you the trade-in value after the trade-in is finalized.
The trade-in value of the old iPad is less than the value we paid via credit card, so we would reasonably assume that they would refund the total trade-in value to our credit card. But nope. They actually calculated the original gift card vs. credit card split ratio, and refunded according to that ratio.
A simplified example is say we paid $200 via gift card plus $300 via credit card for an $500 iPad, with trade-in value of $200 for the old iPad. Instead of refunding $200 to our credit card (so it's eventually $200 via gift card and $100 via credit card), they refunded us $120 to credit card and gave us another $80 gift card. So we have to find ways to spend that gift card again, and it cannot involve any trade-in (otherwise we're not going to be able to use it fully).
I'm not sure it works that way. _In general_ before the recent announcement you are supposed to sign the debug build (what you feed into adb to install) with your debug key that's different from the release nor upload key, and the debug key is never submitted to google.
Of course _maybe_ at some point google will also force you to submit your debug key to them. But I don't believe that's the case now.
I don't understand how this got so many upvotes. Embedded struct fields are never "promoted", you always need to access them via the embedded type's name, so there's nothing to conflict.
The only thing "promoted" are the functions associated with the embedded types, and when those actually conflicts, the compiler will tell you, as expected.
> you always need to access them via the embedded type's name, so there's nothing to conflict.
The article talks about "opts.URL" in its example being accepted by the compiler, which accesses "opts.FooService.URL" without using the embedded type's name.
I tried to use fish on some of my debian servers that i only rarely update packages/kernel, so I don't have to carry my bashrc there, but found their completion for apt is pretty naive. for example after updated kernel i would want to clean up the old ones, but `apt purge linux-image-<TAB>` would list all available kernel versions, not just the ones currently installed.
it has guest support (so people does not need a matrix account to comment), but if you use your own matrix account, you are essentially joining a matrix room per post.
The request body on the client do a lot of other things than reading the body once (an io.Reader can only be read once).
There's Content-Length, and there's also the need to read it multiple times in case a redirect happens (so the same body need to be sent again when being redirected).
As a result, the implementation in stdlib would check a few common io.Reader implementations (bytes.Buffer, bytes.Reader, strings.Reader) and make sure it stores something that can be read multiple times (if it's none of the 3, it's read fully into memory and stored instead).
This is the same basic reply as the other one but my thoughts are roughly the same. The only comment I have aside from what I replied on the sibling comment (this just being another case of wrappers not being transparent biting us in the ass) is that they could've done this in a more generic way than they did, at the downside of requiring more interfaces.
Yea I saw your other reply later and agree on most of it. But I'd say there's a balance between simplicity of the API and more specific cases. For example they can make an optional api to io.Reader to provide size info, and maybe another optional api to io.Reader to make it able to be read more than once, etc.. But at the same time, if you have all those info, that _usually_ means you already have either a []byte or string, and you would most likely use one of the 3 types to convert that into an io.Reader, so that special handling is enough without adding more public apis, and the go team is notoriously conservative when adding new public apis.
Garmin's hardware, including the hardware of their smartwatches, are very tempting. They are designed to be easy to use even with gloves, have good battery life, and on some high end they have solar and/or 40-meter scuba diving rated.
If there's a way to use Garmin's smartwatches without using their cloud I probably would consider that. But since their ransomware attack from 2020, I really can no longer trust their cloud any more, especially that the data collected from a smartwatch is on the more sensitive side. The only Garmin hardware I'm still using is their bicycle tail light+radar, which I just use with wahoo's bike computer instead of other Garmin products.
I had a facebook account from the early days. I deleted my facebook account at 2018-ish. I never had an instagram account.
Recently I got an email from instagram saying it's "easier to get back to instagram", with my usual username. I can't check what's on that instagram user because they don't show you anything without logging in, so I asked my wife to check that instagram user for me. It doesn't have any photos nor profile photo or following, but it does have several followers that's my facebook friends (when I had the account), so at some point meta created that instagram account for me and associated it with my facebook account, I guess? I hope that account was not "AI-powered".
Many years ago we had an iMac at the house as the shared desktop computer. After a few years, it started to have the signs that the harddisk is going to fail, and also we were mostly moved away from Apple's ecosystem, so we decided to trade it in and replace it with something else that's not from Apple.
Since we don't have anything immediate to buy from Apple, we traded it in with Apple gift cards.
Later, my partner needed to trade in an old iPad for a new one, so we used that gift card with credit card for the trade in. For that trade in, you first pay the full price with gift card+credit card, then they refund you the trade-in value after the trade-in is finalized.
The trade-in value of the old iPad is less than the value we paid via credit card, so we would reasonably assume that they would refund the total trade-in value to our credit card. But nope. They actually calculated the original gift card vs. credit card split ratio, and refunded according to that ratio.
A simplified example is say we paid $200 via gift card plus $300 via credit card for an $500 iPad, with trade-in value of $200 for the old iPad. Instead of refunding $200 to our credit card (so it's eventually $200 via gift card and $100 via credit card), they refunded us $120 to credit card and gave us another $80 gift card. So we have to find ways to spend that gift card again, and it cannot involve any trade-in (otherwise we're not going to be able to use it fully).
reply