It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
Those web sites often where much more usable than a lot of todays web sites. :P

My main complaint is not about using JavaScript at all, but about the amount of used JavaScript, doing things unnecessarily in JavaScript, yet even reimplementing standard HTML functionality in JavaScript, like opening a URL, which does not only increase the amount of JavaScript, but also makes pages less user friendly.
Post edited June 08, 2018 by eiii
avatar
avatar
eiii: Those web sites often where much more usable then a lot of todays web sites. :P

My main complain is not about using JavaScript at all, but about the amount of used JavaScript, doing things unnecessarily in JavaScript, yet even reimplementing standard HTML functionality in JavaScript, like opening an URL, which does not only increase the amount of JavaScript, but also makes pages less user friendly.
I'm sure there are plenty of poorly done pages on the Internet.

That said, whether you like it or not, a modern browser is not a piece of software for rendering HTML, it's really an engine for running JavaScript. The good news is, that it isn't the same JavaScript that we had 20 years ago, that was used to make things blink. It has matured substantially, especially in the past 3-4 years. There are a lot of very good reasons to do all of this web-related stuff on the front end.
avatar
USERNAME:kohlrak#Q&_^Q&Q#GROUP:4#Q&_^Q&Q#LINK:59#Q&_^Q&Q#These are "universal practices." Another issue is, like i said, those external dependencies. You grab a JS file, think you're doing it right, them bam, only to find out that something goes missing month's later. This "build" thing seems to help against that (i assume it pulls in all dependencies and makes your program dependency free), but it's only a matter of time before people find ways around it, because they want exclusive control over some of their code. Right now, dependencies are only a problem with javascript if you don't build or rely on certain browser functionality (which is a problem with JS overall, and my main reason for hating webdev).#Q&_^Q&Q#LINK:59#Q&_^Q&Q#
avatar
Well, compatibility is very much my expertise, and that's where the danger comes in. And sometimes not everything's supported on a target you expect it to be. IIRC, Node.js was designed precisely to address this issue. Don't get me wrong, i think it's perfectly fine to avoid dependencies, but one should always ask first how much you'd really save. Go through the effort to do a pseudocode idea in your head. Always make an effort to understand the library you import, since there may be other libraries that are similar but solve the problem better for your scenario, even if for most people the library you're using worked better. This is what lead to my branch: i wanted to know why everything i was doing was so slow on windows XP, even though all i was doing was a simple console program that spit out letters on the screen. I fell for the "information hiding" hook, line, and sinker. I didn't need to know how exactly cout worked, but I did need to know that it wasn't thread safe at the time, but printf was, and that cout usually called printf to print 1 letter at a time. That level of knowledge helped me further understand how to do threads properly. You don't have to know all the underlying mechanisms, but you should have a rough idea, so if something goes wrong, you have a clue where in your own code to start looking. It is for this reason that banks hate to upgrade software: alot of coders aren't aware of inherent rounding errors in their code. That kind of stuff you're not going to get when reading a review for library x, and if you don't know to test for it, you won't.
Post edited June 08, 2018 by kohlrak
avatar
kohlrak: Well, compatibility is very much my expertise, and that's where the danger comes in. And sometimes not everything's supported on a target you expect it to be. IIRC, Node.js was designed precisely to address this issue. Don't get me wrong, i think it's perfectly fine to avoid dependencies, but one should always ask first how much you'd really save. Go through the effort to do a pseudocode idea in your head. Always make an effort to understand the library you import, since there may be other libraries that are similar but solve the problem better for your scenario, even if for most people the library you're using worked better. This is what lead to my branch: i wanted to know why everything i was doing was so slow on windows XP, even though all i was doing was a simple console program that spit out letters on the screen. I fell for the "information hiding" hook, line, and sinker. I didn't need to know how exactly cout worked, but I did need to know that it wasn't thread safe at the time, but printf was, and that cout usually called printf to print 1 letter at a time. That level of knowledge helped me further understand how to do threads properly. You don't have to know all the underlying mechanisms, but you should have a rough idea, so if something goes wrong, you have a clue where in your own code to start looking. It is for this reason that banks hate to upgrade software: alot of coders aren't aware of inherent rounding errors in their code. That kind of stuff you're not going to get when reading a review for library x, and if you don't know to test for it, you won't.
I don't see anything wrong with what you just said. I also don't think I ever said anything to contradict any of it.
avatar
USERNAME:kohlrak#Q&_^Q&Q#GROUP:4#Q&_^Q&Q#LINK:63#Q&_^Q&Q#Well, compatibility is very much my expertise, and that's where the danger comes in. And sometimes not everything's supported on a target you expect it to be. IIRC, Node.js was designed precisely to address this issue. Don't get me wrong, i think it's perfectly fine to avoid dependencies, but one should always ask first how much you'd really save. Go through the effort to do a pseudocode idea in your head. Always make an effort to understand the library you import, since there may be other libraries that are similar but solve the problem better for your scenario, even if for most people the library you're using worked better. This is what lead to my branch: i wanted to know why everything i was doing was so slow on windows XP, even though all i was doing was a simple console program that spit out letters on the screen. I fell for the "information hiding" hook, line, and sinker. I didn't need to know how exactly cout worked, but I did need to know that it wasn't thread safe at the time, but printf was, and that cout usually called printf to print 1 letter at a time. That level of knowledge helped me further understand how to do threads properly. You don't have to know all the underlying mechanisms, but you should have a rough idea, so if something goes wrong, you have a clue where in your own code to start looking. It is for this reason that banks hate to upgrade software: alot of coders aren't aware of inherent rounding errors in their code. That kind of stuff you're not going to get when reading a review for library x, and if you don't know to test for it, you won't.#Q&_^Q&Q#LINK:63#Q&_^Q&Q#
avatar
All i said was to be wary of what you include, and that one should avoid remote hosting. You're the one that found the conflict. XD
avatar
eiii: I get it every time when I want to check or redeem a code and sometimes when I want to log in, even with 2-factor authentication enabled. And it always is a major pain to get that crap even running.
Strange, I redeemed my Rime code without being asked to do a captcha.
I wholeheartedly abhor this captcha. whoever developed this should perish infinitely in a most painful way till the End of the Universe.
it's just awful timesink with luck-based success determination.
a year ago this was implemented in national web database, which I needed to access several times a day because of my job. glad they replaced it by now, but hate it everywhere else it pops up. and unfortunately this bloody crap pops up quite often.
Something must have changed with the way it works, at least on here and the redeem page. Until recently it was enough to temp allow google.com and gstatic.com in NoScript and RequestPolicy Continued to get the bloody captcha, but now I have additionally to disable uBlock Origin on the redeem page.

Anyone else noticed this, or is it just me?
high rated
I have been asking GOG to provide alternative to unlocking account after CAPTCHA-lock for years. It's either "we'll forward this to our web development team" or "we do not offer an alternative," which apparently in itself is a lie of omission since Chinese users have something else to work with. Even dismissing that one, GOG already has a two-step authorization in place, just does not want to allow an option for user to pick THAT for unlocking account instead of Google data-mining. Kind of making me suspicious of the reason there.

Just got a "hehe, you plebe, get in line and bend over for Google" response asking to have the "free" Rime added to my library. Ironically enough, last year (or maybe the year before), it was something GOG did without any particular hesitation.

FFS, the code is already tied to my account. I'm already upset at the use of third-party scripts from a business relying on data-mining for existence. The request is not something that is, from a technical point, difficult to do, nor is it something dangerous from legal point, either. Why the refusal, other than onset of corporate culture of "fuck you, customer, I AM THE LAW!"

In between changes to Privacy Policy, "social media" trackers all over the place (at least we can still block them without the website going dead), the Facebook thing, and constant pressure to have users bend over for Google, I really, really do not like the implications.

If it's all circumstantial, GOG should rethink its approach to users' privacy. I said it before, I'll say it again - GOG did not achieve its success by following what other businesses were doing, but rather the contrary (non-DRM stance). Privacy is another area that they could use to differentiate themselves from the rest of the market, and ensure loyalty of quite a lot of people along the way. On the other hand, going the Steam route (GDPR-required disclosure confirmed what I only heard unofficially from people in the industry, that Steam is working closely with Google and feeding crapton of metrics to the latter) is just going to piss off those of us still considering privacy a non-trade-able good (or at least something valuable, not to be handed out just because).
avatar
SirPrimalform: Strange, I redeemed my Rime code without being asked to do a captcha.
There's an icon on the page that we believe is doing some sort of check. If you don;t pass it, you get the popup with the pictures.

Forgive me for not giving specifics or details but the most simple of checks is to see if Javascript fires up. Probably something like that.
Post edited June 18, 2018 by drmike
high rated
avatar
drmike: There's an icon on the page that we believe is doing some sort of check. If you don;t pass it, you get the popup with the pictures.

Forgive me for not giving specifics or details but the most simple of checks is to see if Javascript fires up. Probably something like that.
I've never been able to redeem anything without running into CAPTCHA.

GOG and its scripts are white-listed, so it has to be something third-party.

What annoys me the most is inability to link a code already associated with my own bloody account with said account without bending over for Google.

You already verified my identity allowing me to log into my account, GOG. Why isn't there simply a button for adding a game already linked to my account straight to my library?

I can understand the need for a security check (not necessarily one from Google, though) for a "gift" code received by somebody else than the account generating it, but this?

Lazy, at best.
avatar
Lukaszmik: I can understand the need for a security check (not necessarily one from Google, though) for a "gift" code received by somebody else than the account generating it, but this?
As a programmer, some times the easiest solution is to use a third party solution.
avatar
Lukaszmik: I can understand the need for a security check (not necessarily one from Google, though) for a "gift" code received by somebody else than the account generating it, but this?
avatar
drmike: As a programmer, some times the easiest solution is to use a third party solution.
Especially when it comes to security, it's far too easy to fuck up when trying to invent a better wheel.
high rated
avatar
drmike: As a programmer, some times the easiest solution is to use a third party solution.
avatar
Maighstir: Especially when it comes to security, it's far too easy to fuck up when trying to invent a better wheel.
As an old-school programmer, I find this approach worrisome.

We are not talking about some multi-million-line code here. If you are using third-party scripts on your web site, and your web site stops functioning when they are blocked, that's both poor implementation and poor security practice.

If it's something critical to your web site, then it should behoove you to study those libraries until you can write your own version, understanding exactly what they do, and plugging any potential security holes.

I realize this is not something looked favorably on in current "cheapest way possible" business, but I would have been professionally ashamed to make my code utterly dependent on the availability of third-party libraries for something as simple as a web site.

At worst, host those elements on your own server!
avatar
Maighstir: Especially when it comes to security, it's far too easy to fuck up when trying to invent a better wheel.
avatar
Lukaszmik: As an old-school programmer, I find this approach worrisome.

We are not talking about some multi-million-line code here. If you are using third-party scripts on your web site, and your web site stops functioning when they are blocked, that's both poor implementation and poor security practice.

If it's something critical to your web site, then it should behoove you to study those libraries until you can write your own version, understanding exactly what they do, and plugging any potential security holes.

I realize this is not something looked favorably on in current "cheapest way possible" business, but I would have been professionally ashamed to make my code utterly dependent on the availability of third-party libraries for something as simple as a web site.

At worst, host those elements on your own server!
Now, I'm not saying I agree with the link-to-script-on-thirdparty-host bandwagon, and absolutely would prefer that everything necessary be hosted by the first-party, but creating a half-decent CAPTCHA isn't all too easy.

Scrambled-text CAPTCHAs are easy to create, but are also by now easier to pass for a computer than a human, thus completely invalidating the point of them. Which is why we're now often told to identify objects in an image - the thing about that, though, is that you need a fairly large library of images and relevant metadata for the system to be effective, something I doubt GOG have, or have the resources to create.

Granted, Google's system is not only for validating that you're a human, but also used as training data for their image recognition algorithms (some images you get are "we know what this is, do you?" while others are "we're not sure what this is, can you tell us?", and you don't get to know which is which), so in time said system will be useless too, at which point new methods will have to have been invented.
Post edited June 19, 2018 by Maighstir