3 ms·
The website gives me a notification saying "looks like you're based in the Netherlands..." regarding VAT. Interesting approach, but alas I'm in Belgium (next to
by Insanity 6y ago
The website gives me a notification saying "looks like you're based in the Netherlands..." regarding VAT. Interesting approach, but alas I'm in Belgium (next to NL) and not even close to the border.. :)
- gregdoesit 6y agoSorry about that, I didn't do it on purpose! I use the service https://ipstack.com https://ipstack.com to look up IPs and use their data to display discounts based on location. I pay for this, so I was hoping it's better quality than it is.
- tomedme 6y agoI'm in South Korea and the banner claims I'm in United Arab Emirates, however it shows the correct flag for my location. 218.146.64.x is my IP address range. Thanks for writing the book!
- jacurtis 6y agoI live in Northern Washington, USA and routinely get kicked over to Canadian versions of large websites, including Google and occasionally Amazon. So all of these are imperfect systems. Your website appears to be recognizing me as from the US, which is correct. For whatever value that anecdote is worth to you.
- Eugeleo 6y agoI’d report a bug I were you, then. It showed the correct flag for me (Czech Republic), but told me I’m in Portugal. Seems like the do know wwhere I am and just mess up the name.
- brnt 6y agoThe author seems a helpful fellow future proofing his website :) I do live near a border and YouTube thinks I'm in the other country all the time. I suspect European borders may have more resolution than Californian algorithms.
- gregdoesit 6y agoOkay, so I hunted this bug down and it was in my code, an interesting one. Sharing it here for amusement. The endpoint returning the string of "Looks like you're based in Netherlands" is a nodej.js script that has this defined in the top: const MESSAGE = "Hey - it looks like you're based in $countryName." Sometime later in the code, in a function I manipulate this string in the module's export function: module.exports.getDiscountData = function(countryCode, countyName, etc) { // Fetch the right message let message = counryValues[countryCode]; // We get MESSAGE message = MESSAGE.replace("$countryName", countryName) // oops - we overwrote MESSAGE with a new value! message = MESSAGE.replace("$otherVariable", etc) return message; } And for each country, I have keys /values listed, like: "GB": MESSAGE, "NL": MESSAGE, "HU": MESSAGE_2 The problem was that once the first request replaced the country name, MESSAGE was mutated, and it now had the value "Hey - it looks like you're based in Netherlands." instead of "Hey - it looks like you're based in $countryName." I had no idea this would happen. And that a "const" in Javascript is a mutable thing. I fixed it by deep copying the string of the original message. The super interesting part is that I did not notice this problem, as when I was testing, I did low frequency testing. As I am using Lambda, I probably got a new container created, where MESSAGE was re-initialized. But with the HN traffic, the containers stayed alive longer, making this mutated string issue a problem.
- dragonwriter 6y agoAt first, this sounds like the familiar blues of “I got bit by an immutable reference to a mutable object”, but something seems...off. Const in JS is an immutable reference that doesn't change the mutability of the value referenced, so an object will be mutable though you can't reassign a different object. By JS strings are immutable, and String.prototype.replace doesn't modify in place, it returns a fresh string. So, this shouldn't be possible as described.