I’ve seen it before—a SaaS claiming to offer end-to-end encryption simply because it uses HTTPS/SSL for communication between the client and server. It’s laughable, but the lack of clear regulations or standards defining E2E encryption lets them get away with treating the client and server as the “ends.”
Not sure if that’s what happened here but it wouldn’t surprise me.
> The settlement, which only applies to US merchants, is the result of a lawsuit filed in 2005. However, nothing is considered finalized until it receives approval from the US District Court for the Eastern District of New York.
> Typically, swipe fees cost merchants 2% of the total transaction a customer makes — but can be as much as 4% for some premium rewards cards, according to the National Retail Federation. The settlement would lower those fees by at least 0.04 percentage point for a minimum of three years.
It took a 20 year antitrust lawsuit to bring a 2% fee down to 1.96% for 3 years? Am I reading that wrong? Or maybe this is more about reducing the additional fees for premium rewards cards?
"When the litigation began in 2005, average interchange fees were 1.75%. After the settlement, they will be at 2.19%"
"Credit card interchange fees after the settlement will be 25% higher than when the litigation began."
"When the litigation began in 2005, American merchants paid the highest interchange fees in the developed world. After the settlement, American merchants will still pay the highest interchange fees in the developed world."
For the uninitiated, the projects mentioned here are PC Ports of the N64 Zelda games. The port for Ocarina of Time (https://www.shipofharkinian.com/) has been publicly available for around 2 years now, and we are getting close to the first release of the Majora's Mask port (2 Ship 2 Harkinian)
Love to automate these types of things. Unfortunately there isn't much benefit to automating the shopping/leveling, as this performs far better than any passive bonus those provide
let stop = false;
let play = () => {
const button = document.querySelector('[data-word-button]');
if (stop || !button) return;
button.click();
setTimeout(play, 0);
}
play(); // to play
stop = true; // to stop
localStorage.clear(); location.reload(); // to restart
Thanks for your concern around possible naming conflicts!
Actually the name is deliberate. A homage to jquery, at first I even considered calling this library JCustom. I think the logic is cool, as Hyphen aspires to be a kind of layer atop custom elements, as JQuery was a layer atop the DOM (and MUCH more!).
Yet, the age of JQuery has passed. It's light has gone out of the world, and John Resig has retreated to the West with the Elves.
I don't think it's really an issue.
Also, it's time to consider that passing the torch of '$' is ok. Moreover, perhaps it was never not ok. As in, the existence of a library that binds to a tiny symbol should not restrict others from using the same symbol. Otherwise it would be kind of like 'variable name squatting'--not good! Dollars for all, I say! Who's with me???
So while I get your concern about conflicts there's always been ways to avoid namespace conflicts, such that these avoidance functions have been built into the libraries themselves, in the form of: noConflict().
I think that's sufficient.
And, not that it's the best guide of best practice, but for a long time Chrome, Safar and Firefox have included $, $$ and so on functions in their consoles, as part of the Web Console API.
I get you might be concerned about this, so you can easily modify this tiny base class of Hyphen to call the base whatever you like. Reasonably, there's plenty of names that could be good for a base class, given whatever it is that you might want! :)
For me, tho, I think $ is a beautiful symbol to name it after so I'm sticking with that. JQuery can bind to other symbols, but it's also not as common these days. I'm not worried about it.
Do you think I should be worried about this? If so why?
Obvious if you've been around long enough. I wouldn't be surprised if the majority of people reading this have never actually worked with jquery, only heard the bedtime horror stories.
(I mean, leaving aside the fact that it's utterly nondescriptive...)
I used jQuery in a few personal projects and it was very useful. It was 10 - 15 years ago, so I am sure there are better tools now, but for a hobbyist it was great.
The syntax still seems much more pleasant for DOM manipulation than vanillaJS. It had a nice pseudo-functional interface and a ton of elegant helpers. Whenever I do DOM manipulation in vanilla I wonder to myself if the API couldn't be a bit more user-friendly and readable.
Yeah it seems like a ripoff, I’m sure in a couple years more capable, cheaper cards will come out (and then people still playing this game can enjoy it with all the bells and whistles).
Not sure if that’s what happened here but it wouldn’t surprise me.