The moderators of this message board, otatop, L.Washington, WichitaDM, Yuv, JonnyA, RiskyFlush, and SvenO, are cowards who let abusers dox and harrass other long time posters.
The way I did it for the sidebar was basically this, as an array:
var xmlhttp = new XMLHttpRequest();
xmlhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
var myArr = JSON.parse(this.responseText);
document.getElementById("demo").innerHTML = myArr[0];
}
};
xmlhttp.open("GET", "json_demo_array.txt", true);
xmlhttp.send();
The moderators of this message board, otatop, L.Washington, WichitaDM, Yuv, JonnyA, RiskyFlush, and SvenO, are cowards who let abusers dox and harrass other long time posters.
How would you describe the container component of MVC in an interview?
Clearly
As the controller?
At some point in the near future I’m going to be putting my resume up online and doing linked-in primarily in hopes of getting some contract work. I have some old professional experience as a LAMP developer, some recent experience on a contract as a node developer, and miscellaneous work on my own projects in LAMP, React, and a little Python. I’d really like to get Python work. I expect to have pretty warm contacts looking at these things because I have a lot of friends in IT/Programming and they in turn have a lot of friends, so it’s not as hopeless as it might seem.
Do you think taking courses and those certificates from places like coursera will help? Maybe hurt because they make you look more like a n00b? If the answer is that they probably won’t make a difference in getting a jerb, but learning more stuff is good - I probably wouldn’t do it. Learning stuff is good for sure and I would learn stuff, but looking good on a place like linked-in would be part of the reason for doing it.
It actually threw me. I was like - wait what is the container part of MVC? Then I felt old and stupid because I couldn’t picture it.
Are you willing to work for cheap + a little bit of equity? If so, I may be able to hook you up with a hot new startup…
On this front, all the advice to look at React was good. I read some articles saying that Vue was easier to learn, but the authors are all apparently lunatics, because Vue makes no sense and React is very clear (complicated, obviously, but logical and organized). And, as micro said, the docs are fantastic, at the ones explaining concepts!
Two noob questions:
-
On my word search project, I want to validate the words that are input against a dictionary so that I’m not wasting time asking the API for pictures of a “raibnow.” Is there an easy way to do this? I had assumed it would be easy to ask the browser if the word is spelled correctly, but that does not appear to be the case. I think that I can just do the spellchecking trivially on the server side, or I could send my own dictionary to the browser, but I wanted to make sure I’m not overlooking something obvious?
-
Can someone explain the following results:
numArr = [1, 2, 3, 4]
(4) [1, 2, 3, 4]
double = n => 2 * n
n => 2 * n
numArr.map(double) // works as expected, as does numArr.map(n => 2 * n)
(4) [2, 4, 6, 8]
strArr = [“1”, “2”, “3”, “4”]
(4) [“1”, “2”, “3”, “4”]
strArr.map(parseInt) // doesn’t work??
(4) [1, NaN, NaN, NaN]
parse = s => parseInt(s)
s => parseInt(s)
strArr.map(parse) // back to working, as does strArr.map(s => parseInt(s))
(4) [1, 2, 3, 4]
![]()
I guessed that it had something to do with parameter passing, and that appears to be the case: javascript - Why does parseInt yield NaN with Array#map? - Stack Overflow
Array.map provides more than one argument to the callback. When you do map(s => parseInt(s)) you’re explicitly only processing the first argument, which is the actual array item. When you give map the function reference directly it will end up passing the array index as a second argument to parseInt, which it interprets as the radix.
You can see the effects of this more easily with a carefully constructed array like
["0", "1", "0", "2", "33"].map(parseInt)
> (5) [0, NaN, 0, 2, 15] // "33" == 15 in base 4
strArr = [“1”, “2”, “3”, “4”]
(4) [“1”, “2”, “3”, “4”]strArr.map(parseInt
Well for one thing your curly quotes make copying hard. Not sure how those got in there but when I replace them I still match your result.
The problem is parseInt takes more than one parameter, which array.map is also providing when it sends index as the second parameter. javascript - Why does parseInt yield NaN with Array#map? - Stack Overflow
Ponied!
I’m willing to do a little bit of work for a little bit of money and a little bit of equity. PM me though if you’re serious. I consider myself NDA’d.
On my word search project, I want to validate the words that are input against a dictionary so that I’m not wasting time asking the API for pictures of a “raibnow.” Is there an easy way to do this? I had assumed it would be easy to ask the browser if the word is spelled correctly, but that does not appear to be the case. I think that I can just do the spellchecking trivially on the server side, or I could send my own dictionary to the browser, but I wanted to make sure I’m not overlooking something obvious?
I don’t think it’s possible to access the browser spell checker. I think that’s mostly out of privacy concerns given that individuals spell check dictionaries might contain sensitive information.
I’ve seen some people use Google results as a spell checker. You get more results for a correctly spelled word and you can scrape the suggestions. Doesn’t seem good or reliable though.
Bing seems to have a spellcheck API.
The moderators of this message board, otatop, L.Washington, WichitaDM, Yuv, JonnyA, RiskyFlush, and SvenO, are cowards who let abusers dox and harrass other long time posters.
One more thing on the parseInt stuff - in general I try to avoid explicit type conversion in JS. The language is designed to be malleable and the best way to use it as intended is to let it do its thing - meaning if you worry about strings in your ints - look at your data or code further up the line first.
The exception is validating user input. For which parseInt is fine I guess. But I generally just tend to validate on the client, then multiply the server-side input by 1 or something if I need to make sure. (don’t add zero or “some string” will turn into “some string0”)
An important advanced programming concept is to differentiate between things that should break as a normal course of action - and therefore need to be handled gracefully vs. things that should never break and therefore can be handled roughly - as long as it doesn’t bring down the whole system or open a security hole.
So in the case of user input - validate on the client and handle malformed input gracefully. The most graceful way imo is usually just to not even let them type a letter into an all number field. But beware the HTML 5 number field type - it generally doesn’t do what you want - neither does the iOS numeric keyboard. Whole other story.
So now that we’ve handled the normal course of operation gracefully - the only way a string can come to the server as a number field is if the client code is broken (which we should fix at the client rather than try to handle at the server) or if the user is trying to hack our API. Either way - breaking non-gracefully is fine. Just make sure it can’t crash the system, and doesn’t return some information-laden stack trace in production.
This concept applies to a lot more than just client-server. I see sooooooooo much code that’s got defensive exceptions, attempting to handle errors gracefully, all up and down the chain and it’s such a giant mess. If it’s your code talking to your code - never code defensively - just fix the errors. Only worry about graceful error handling for stuff like user input, 3rd party clients, unclean data you can’t do anything about, etc.
But what if I plan to extend this someday to become a 3rd party lib? NO! [BATMAN SLAP] See ChrisV’s post about the inner-platform anti-pattern.
Just code to do exactly what you need - then refactor when you get a second use case. Otherwise you’re guessing at a lot of stuff. It’s much easier to add a new layer of abstraction to simple straightforward code than it is to remove an unnecessary one (which is often impossible by the time you realize you don’t need it).
One more thing on the parseInt stuff - in general I try to avoid explicit type conversion in JS. The language is designed to be malleable and the best way to use it as intended is to let it do its thing - meaning if you worry about strings in your ints - look at your data or code further up the line first.
The exception is validating user input. For which parseInt is fine I guess. But I generally just tend to validate on the client, then multiply the server-side input by 1 or something if I need to make sure. (don’t add zero or “some string” will turn into “some string0”)
An important advanced programming concept is to differentiate between things that should break as a normal course of action - and therefore need to be handled gracefully vs. things that should never break and therefore can be handled roughly - as long as it doesn’t bring down the whole system or open a security hole.
So in the case of user input - validate on the client and handle malformed input gracefully. The most graceful way imo is usually just to not even let them type a letter into an all number field. But beware the HTML 5 number field type - it generally doesn’t do what you want - neither does the iOS numeric keyboard. Whole other story.
So now that we’ve handled the normal course of operation gracefully - the only way a string can come to the server as a number field is if the client code is broken (which we should fix at the client rather than try to handle at the server) or if the user is trying to hack our API. Either way - breaking non-gracefully is fine. Just make sure it can’t crash the system, and doesn’t return some information-laden stack trace in production.
This concept applies to a lot more than just client-server. I see sooooooooo much code that’s got defensive exceptions, attempting to handle errors gracefully, all up and down the chain and it’s such a giant mess. If it’s your code talking to your code - never code defensively - just fix the errors. Only worry about graceful error handling for stuff like user input, 3rd party clients, unclean data you can’t do anything about, etc.
But what if I plan to extend this someday to become a 3rd party lib? NO! [BATMAN SLAP] See ChrisV’s post about the inner-platform anti-pattern.
Just code to do exactly what you need - then refactor when you get a second use case. Otherwise you’re guessing at a lot of stuff. It’s much easier to add a new layer of abstraction to simple straightforward code than it is to remove an unnecessary one (which is often impossible by the time you realize you don’t need it).
Thanks, this is all very interesting. I actually started out the lazy way (not because it’s the JS way, just because I’m lazy…). The background for this question was actually not user input, it was a coding puzzle where the string was input for a numerical puzzle (i.e., it was a list of entries that were in the form “(1, 2): (3,4)”. My original approach was:
let (x, y) = pair.split(“,”);
But then I got burned (two separate times!) later when I added x and y and got 12, so I decided that my laziness had been sinful and I needed to convert the data. In reality, what I did was:
let (x, y) = pair.split(“,”);
x = Number(x);
y = Number(y);
Which is a little inelegant, so I was trying to figure out a more concise way.
The moderators of this message board, otatop, L.Washington, WichitaDM, Yuv, JonnyA, RiskyFlush, and SvenO, are cowards who let abusers dox and harrass other long time posters.
