|
|
There are some checking tools for javascript out there, like lint. Good luck 
PS: I got headaches because of some "platform specific issues" of my tool chain and imcomplete binaries. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
you keep saying "compiler" but in JavaScript there's no such thing. JavaScript runs under an interpreter, that's why you're able to have such things as eval("javascript code here").  The closest thing you may get to a compiler is to using something like jslint.
Edit:
I've seen your compiler links. Interesting. So yeah, you've a point.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
modified 12-Jan-19 12:38pm.
|
|
|
|
|
1) Use a proper IDE with linter
/thread
|
|
|
|
|
That would make it a good habit to always prefix your variale names with "v", and have class factories not start with "v". Contains the damage a bit.
Also, your variable is now vroom!
|
|
|
|
|
"devs" don't hate JavaScript.
Also don't blame someone else for your mistakes (you use a style of JS that was written like 10 years ago; TypeScript is out there since 2012 and you are still not using arrow functions, let, strict mode, and other goodies that are there to help you to avoid such mistakes). I am not sure why you "compile" at all when you essentially write ES3 code.
|
|
|
|
|
At 6:53pm on November 26 (New Zealand time), we deployed this 3.4.5c patch and it contained a significant bug. Due to a typo in a database key comparison function, if two users returned to the character selection screen at exactly the same time, there was a chance that one person was logged into the other's account.
This was not apparent to us during testing because it requires a lot of players to be online before it occurs. Upon it being reported, we took the realm down at 8:26pm and restored the old version that did not have this problem.
417 players had their accounts accessed by another user. Of those, only 150 actually tried to log into a character. Most of these either logged out within a few seconds or were kicked off as the owner logged in again immediately.
I'll admit I'm really curious what their code looked like to make that possible in the first place.
Their backend is primarily Linux/C++. but I'm not sure if that is just the main game server code, or also webapi's too. I know the website is php, but based on the history of serious exploitable bugs (almost all of which required crashing a game server before state was saved to the database for local rollbacks of failed crafting attempts, off hand I can only think of one other that didn't and it was a devops failure) I'm skeptical that they're using php for any critical infrastructure.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: Due to a typo in a database key comparison function
Something like:
if (logonToken != currentLogonToken)
perhaps?
cheers
Chris Maunder
|
|
|
|
|
An == where a != was expected or vice versa is almost a given.
What I'm not getting is what the slightly bigger picture looked like. They said it only happened when 2 people logged in simultaneously. But since each login attempt should be independent of any others that suggests that somewhere they're at least temporarily storing a value used in the login process as a global/static/etc variable, without that person A and person B's login threads/etc should have zero shared state and be unable to affect each other. I can't see any legitimate reason to do that, which means that if true the bit of shared state would be a much bigger issue than a bad comparison.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Another option is they are loading state (eg session state) based on current user values and getting back the wrong state.
cheers
Chris Maunder
|
|
|
|
|
Dan Neely wrote: I'm really curious what their code looked like to make that possible in the first place.
I would guess that Time is relative my dear Watson.
int seed = time(NULL);
srand(seed);
key = generate_session_key();
Just a guess. Although the phrase 'at the same time' implies the bug was time dependent.
Best Wishes,
-David Delaune
modified 4-Dec-18 3:33am.
|
|
|
|
|
I think that is a really good guess at what might've happened.
But, a production-ready web server wouldn't do that, right?
You're saying that devs are generating some session and have written buggy code, right?
It's interesting that devs do often write "genius" code for things they don't understand completely and for which there are already fully-tested solutions.
|
|
|
|
|
you mean like javascript "rooms"  ?
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: you mean like javascript "rooms"
Yes, exactly like that. 
|
|
|
|
|
I'm learning Swift.
It's an interesting new(er) language that has some interesting new features.
Functions Have External Param Names
One of those features is the naming of external function params.
Background
Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}
Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense.
What About Swift?
But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name.
Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}
You can call that method like :
Add(2,3)
Magical Underscore
However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}
So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This
The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}
What changeName Does
The changeName function takes a Dog class and changes it's name property to the value that is sent in the 2nd param (String).
The external variable for the first param (of type Dog) is of and the internal name of that same param is d. The external name of the 2nd param (String) is to and its internal name is newName.
Now, check out what the final call to that method looks like. It's like readable English but hmm....it feels so odd to be code that it makes me stumble anyways and I'm not sure it really advances understanding.
changeName(of:d, to:"Rover")
Change name of d to rover.
 ? or  ?
modified 19-Nov-18 17:12pm.
|
|
|
|
|
I did kinda like that when I first learned it but then...
I think I'm too steeped in keeping code compact. Not Ruby-esque compact, but the need to explicitly name every input variable started grating.
I do prefer the C# way where naming input parameters is opt-in instead of opt-out.
cheers
Chris Maunder
|
|
|
|
|
Maunder said: the need to explicitly name every input variable started grating.
Yeah i wondered if it might be nifty the first dozen times then become too much.
And I think the example is nifty but so odd to name the vars to help the function call make a natural language sentence.
|
|
|
|
|
Yeah - like a fluid interface. But not really.
cheers
Chris Maunder
|
|
|
|
|
I use this in VB (6, Applications, .Net) sometimes, but I'd prefer to have the option. Most of the time it simply doesn't help the readability of the calling code.
|
|
|
|
|
Gross. So it is foisted onto the development team to making the decision as to which pattern to consistently use: _ so the syntax is changeName(d, "Rover") or to use named external parameters so the syntax is changeName(of:d, to:"Rover"). That is, if it's even a conscious decision.
But of course, the next team / outsource group / other library may use the opposite pattern, so your Swift code will be a smattering of the two, and it seems like the only way to tell which one you need to use is by inspecting the function declaration? Because I seriously doubt whatever editor you use has sophisticated intellisense to help you, or am I wrong in this?
So, what is the benefit of named external parameters? Merely the fact that you can also, if you're Hungarian or like RPN, write changeName(to:"Rover", of:d) ??? Is there any concept of optional parameters that have default values if not set?
And even worse, can you mix the two, so you could write changeName(d, to:"Rover") ?
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Yes, you'd have to decide at the outset if you were really going to follow that type of pattern and it could get very mixed up.
Also, XCode does seem to help with a Intellisense type of functionality.
Marc Clifton wrote: And even worse, can you mix the two,
And, yes, you can definitely mix the two. The creator of the original function can use the _ to indicate the external name is not required and can use it on 0 or more params.
I can see that the language creators were trying to allow developers to convey more meaning but not sure external names really help.
It feels like what has recently been done with fluent interfaces[^]
mock.expects(once()).method("m").with( or(stringContains("hello"), stringContains("howdy")) );
The attempt to make it read like natural language. I think it works well with unit testing frameworks, but not sure about all code.
|
|
|
|
|
I remember that Algol 60 (used in my uni. days) had a different approach. When calling a function, you could separate parameters using either ',' or ') <letter string> :(' to give expressions like
CHANGENAME(D) THE DOG CHANGES NAME TO :( NEWNAME) (we only had uppercase characters  ). I didn't use that syntax very much - it was confusing because the ) looked like an end of a parameter list, not the start of an inline comment
|
|
|
|
|
|
I think partly this is a holdover from Objective-C. For example, this Cocoa method call:
UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Hello!"
message:@"Hello, world!"
delegate:nil
cancelButtonTitle:@"Close"
otherButtonTitles:nil];
which calls initWithTitle to create a new pop-up with a message for the user. It uses the external notation and if I remember correctly (always problematic) the notation was required on all but the first argument, where it was optional.
This used to be more important when mixing Swift with Objective-C, but now most (if not all) of the various OS APIs are implemented in Swift, so it's less relevant. The exception is if you're using your own Objective-C code with Swift, or slowly converting a project over from one to the other.
|
|
|
|
|
Interesting, thanks for explaining by connecting it back to Objective-C.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
