##Question 1
So, you're on the right track, which is great! And I can see what's tripping you up here.
It's what's happening when you click the button and the .onclick function is run. So let's run through this a bit.
When you're going through for loop, each time around, you create a function that will run when the button is clicked.
And there's the trick, that function won't be executed UNTIL the button is clicked. So I want you to look at the code
inside that function and tell me what all of the values would be when that function is executed after you click it.
[PAUSE....] ... maybe get the right or the wrong answer
What's the value of btnNumber when one of the buttons gets clicked.
[PAUSE...]
It's going to be 3. Because the loop doesn't stop until btnNum is BIGGER than prizes.length. So no tell me, where is that undefined value in the alert box coming from?
Right, it's coming from prizes[3]. The 3 comes from the last known value of btnNumber.
The key here is that the functions we're creating and assigning to each button's .onclick property hold a reference to
btnNumber. As the value of btnNumber changes each time we go through the loop, the reference to that value changes as
well. It's like the function can actually remember values declared outside it's scope. This is actually called a closure.
We can talk about that more later. But how do you think we could solve this?
What if, in the loop, we create functions that already know which prize they are supposed to alers?
That might sound magical, but think about the first time the code enters the for-loop.
What's the value of btnNum at that moment?
And how could we get ahold of the right part of the prizes array at that moment?
And given what we now know about how closures work, how could we create a closure that knows what it's supposed to alert ahead of time, instead of relying on the value of btnNumber when the button gets clicked.
[I'd try to chat this out so that they eventually came up with the answer, but I'd direct them to something like this]
<button id="btn-0">Button 1!</button>
<button id="btn-1">Button 2!</button>
<button id="btn-2">Button 3!</button>
<script type="text/javascript">
var prizes = ['A Unicorn!', 'A Hug!', 'Fresh Laundry!'];
for (var btnNum = 0; btnNum < prizes.length; btnNum++) {
// for each of our buttons, when the user clicks it...
document.getElementById('btn-' + btnNum).onclick = function(prize) {
return function() {
alert(prize);
}
}(prizes[btnNum]);
}
</script>
Great question about SQL injection. [First I'd gather what they know about SQL and who is sending SQL to the DB server, etc.]...
So now that we've established that it's the web server that typically sends SQL to the database server, we have to understand how the web server is generating the SQL.
Let's imagine we're in a situation where we have a website where we match up potential friends. It's going to be a simple process. You sign up, select a favorite primary color, and then we show you other people that have that same favorite primary color. It's silly, but hang in there, we'll learn something from this tenuous match-making algorithm.
So our users can select one of the following: 'red', 'blue', 'yellow'.
For the sake of our example, let's say one of the users chooses 'red'.
We'll send that value 'red' to the webserver and ask it to give us back all the users that have the same favorite prime color. So here's what the webserver does. It takes a piece of SQL that looks like this:
select *
from users
where favorite_color = 'red'
Now, what we probably did in our code was to take a string (think a string in ruby or python or whatever language you're learning)
and we added the 'red' part to it. Now remember, we got 'red' from what the browser sent us. The thing we ALWAYS
have to remember is that people can adjust what browsers send us. If you just look in your console in Chrome you can find
all sorts of ways to change stuff that browsers are sending to the web server. So what would happen if, instead of sending us 'red',
they sent us the value 'red'; DELETE * from users;. Well, that would end the current SQL statement and being a new one that deletes
everything in the users table. That's called SQL injection. The user send SQL from the browser to the webserver, and the
webserver just passes that SQL right along to the database, where it maliciously destroys our social network.
The way we protect against it is to take whatever value the browser gives us and run it through a sanitation library. There are a lot of sanitation libraries, your language of choice probably has a great one that is supported by the community.
jQuery is a library because it helps us do tasks. But Angular is a framework because it gives us a way to organize our code, and it gives us a whole set of hand-selected libraries. It's kind of like a very opinionated set of libraries bundled up into one place so that we get a whole bunch of conventions to follow. For example, did you know that javascript can update the URL in the page without requiring a page refresh. It's a fancy thing that a framework can help you with. There are also libraries that could help you do that, but again, a framework is like a curated set of libraries that helps you do things.
Along with this curation, though, comes a set of conventions to help you organize all of your code. Angular gives you a way
to route urls to certain bits of code called controllers. This routing is really helpful and gives you a quick, declarative way to
specify that when the url has X in it, I want to run the code found in file Y, that way you can organize your code effectively.
Really, you'll have to play with frameworks to get the gist of it, but a library is generally considered to be a tool in your toolbelt, and a framework is a toolbelt stock full of tools.
The benefit of a framework is that there are usually consistent themes and conventions built throughout the framework that help guide you along and give you ways to solve common tasks like routing, security, re-using certain types of code, separating concerns like presentation logic from data manipulation, etc.
The drawbck of frameworks is that sometimes you need to do things that the framework didn't plan on you doing. If the framework wasn't created in a flexible way (and frameworks are always made with varying levels of flexibility), then you may spend a LOT of time trying to work against the framework.
Similarly, with libraries, you don't get as much guidance, and if you're not careful, you might end up solving the same problems in different ways or create inconsistencies. The great thing about libraries is that they generally are quicker to learn and help you solve a smaller set of problems quicker.
When thinking about Big O, I generally try to find out how many loops are being created in my algorithm. I'll give you an example. If I have a simple for loop that loops through an array 1 time, then I know my Big O is n. I only had 1 loop that looped over all n items.
Now, if I have a for loop, but rather than just do some simple logic in each loop, it actually does something like call a function that triggers another loop over my data set, that's a different story. See, in this case, each time through the loop, I'm hitting more code that loops over all the items another time. So I have n loops that go over all n items. This puts Big O at n[squared].
- The issue with the CSS is the
float: left. The browser actually has something called the "normal flow" in which it takes HTML elements (like a div or an h1) and it tries to put them in this flow from top left to bottom right.
Now, divs are called "block-level" elements, so they tend to take up an entire line across the screen. So we created something called a "float". You're using it here to keep the div's from each taking up a whole line, but the problem with using float
is that it takes div out of the "normal flow". So those div's don't relate the same to their containers. In this case, what I'd recommend doing is to change the display of the pricing tier div's to inline-block. You can read more about it on the web,
but basically it's going to put those div's back into their parent div where you expect them and also cause them not to
each take up an entire line.
Once you're done with that, I'm going to recommend we have a serious talk about using a flexbox layout. It's going to make your life a lot easier, though it may not be supported by your target browsers, depending on your project.