Don't worry you're definitely not the first person to be confused by this type of problem! Before doing alert(prizes[btnNum]) try alerting just btnNum by itself and see if that gives you a clue as to what's going on.
To solve this problem, remember you can pass the click event to the function that handles it like this:
function(e) {
// do something
};
Try alerting e.target.id inside that function, then see if you can use JavaScript's slice function to get the part of that you need to get the correct prize from your array.
A has_many association is used to represent a one-to-many relationship. The Active Record [documentation] (http://guides.rubyonrails.org/association_basics.html) gives a good example of this: an author can write more than one book, so an author "has many" books.
What about a many-to-many relationship? I'll make up an example: think about recipes and ingredients. Each recipe contains more than one ingredient, and each ingredient can go in more than one recipe. To represent this in a relational database, we actually need three tables: the first for the list of recipes, the second for the list of ingredients, and the third to tell us which ingredient goes in which recipe along with the amount i.e. one cup. In this case, recipes and ingredients never reference each other directly, they are only related to each other via the third table. That's why we have to say a recipe "has many" ingredients "through" that third table, and likewise an ingredient "has many" recipes "through" that table.
You use has_one: through in the case of one-to-many relationships that are chained together. Going back to the example of one author having many books, we also know each book has many pages. However, a page in only in one book, just like a book only has one author. So, we know a page "has one" author, but only "through" that page's book since pages and authors are not directly related.
SQL is cool because it gives you a lot of power to work with your database, however hackers can take advantage of that by passing malicious commands to your database if you're not careful about how you code your application.
Suppose you have a blog with a page that's coded to bring up a specific post based on a post ID passed in the URL, like this:
http://myblog.com/page?post_id=1
Your application might use a SQL command like the following to retrieve that post from the database:
SELECT title, text
FROM posts
WHERE id = 1
Now think about what would happen if someone submitted an ID in the URL string like this:
http://myblog.com/page?post_id=1;DELETE%20FROM%20posts
The SQL statement run by your application would then look like this:
SELECT title, text
FROM posts
WHERE id = 1;DELETE FROM posts
Yikes! Your posts just got zapped. This type of technique can also be used to make database queries accept any password for logging into an account that is supposed to be secure.
The solution to this problem is to make sure you're filtering any input that gets passed to a database query, including from the URL, form fields, and even cookies. Different languages and frameworks have different ways of helping you do this, so be sure to look up what the best practices are for whatever tools you're using. You might not think you're a big target, but hackers are constantly running automated scripts against random websites trying to exploit this type of vulnerability.
You can think of a library like jQuery as one tool in your toolbox for building an application. In the case of jQuery, that tool is focused on helping you work with web browsers. Underscore is another popular library that helps you use the JavaScript language. The cool thing about picking and choosing individual tools you want to use is that it gives you a lot of freedom in how you build an application, and avoids adding unnecessary complexity to a project.
Unfortunately, freedom can lead to chaos as projects get bigger and multiple developers get involved. That's where frameworks like Angular (on the client side) and Ruby on Rails (on the server side) come into play. Frameworks like those give you a soup-to-nuts solution for coding an entire application. The downside of frameworks is that you have to do things a certain way and they take some time to learn, but once you do learn a framework it gives you a lot of power to keep your app organized in a way that scales and that other developers can understand.
First of all, don't stress about this. I've been a professional developer for 17 years and I've never had to figure out which notation an algorithm uses. However, I do have to think about how my code will perform both now and in the future, and have had to solve problems with code written by other people. Learning about things like Big O Notation is a great way to train yourself to be on the lookout for these issues.
The key I've found is to look for loops inside of loops, and the total number of times code inside the inner loops will run. Here's a simple example:
var outerLoop = 2;
var innerLoop = 3;
var count = 0;
for (i=1; i <= outerLoop; i++) {
for (j=1; j <= innerLoop; j++) {
count++;
}
}
console.log(count);
If you run this, you'll see the inner loop runs a total of six times. What you want to notice here is that no matter how many times we run the outer loop, the inner loop will only run three times each time the outer loop runs. So, if you set outerLoop to 100, the count goes up to 300.
Now take a look at a slightly different example:
var outerLoop = 100;
var count = 0;
for (i=1; i <= outerLoop; i++) {
for (j=1; j <= i; j++) {
count++;
}
}
console.log(count);
In this example, since the inner loop runs more and more times as we go through the outer loop, the inner loop runs over 5,000 times! Here’s another version where it runs 10,000 times:
var outerLoop = 100;
var count = 0;
for (i=1; i <= outerLoop; i++) {
for (j=1; j <= outerLoop; j++) {
count++;
}
}
console.log(count);
These three examples illustrate different ways the amount of resources used by an algorithm can grow depending on the size of the input you have to loop over. You can imagine how an algorithm that works like the second or third example could bog down if the input grows to thousands or even millions of items. See if this clarifies how to analyze the amount of resources your algorithm will consume as the input grows.
In Chrome developer tools, if you click on your pricing-tiers div you'll see how its height has collapsed to zero, as has the height of its container the pricing section. This is happening because all the contents of the pricing-tiers div (your tier divs) are floated in this case to the left, and since nothing clears the float nothing is getting pushed down below the bottom of the tier divs, including their container.
The fix for this is to clear the float. Try adding the following style to your stylesheet, then look again at the height of your pricing-tiers div and pricing section in Chrome:
.pricing-tiers:after {
content: ".";
visibility: hidden;
display: block;
height: 0;
clear: both;
}
This trick adds some hidden content (a period character) after the pricing-tiers div, and sets it to clear the float of your tier divs so the pricing-tiers div expands to include them. Here's a good article that covers this and other options.
Also, while floats are great for getting text to wrap around images, in a situation like this where you're stacking elements horizontally I'd recommend using display: inline-block; instead of float: left; on your tier divs so you don’t have to worry about clearing your floats. See if you can re-work your solution accordingly, and remember you can always try out changes in Chrome developer tools to get real-time feedback before editing your html and css files.