So since this is a for
loop the iterator btnNum
keeps increasing after ever loop. Initially when it runs it will declare document.getElementById('btn-' + btnNum).onclick = function() {
for #btn-0
#btn-1
and #btn-2
. The issue lies in when this onclick
is triggered later when a user clicks on the button
when this happens the iterator btnNum
is assigned to 3 since it has kept incrememnting on every loop, you can see this by adding console.log(btnNum);
within the document.getElementById('btn-' + btnNum).onclick = function() {
block.
The easiest way to fix this is actually to get rid of the for
loop entirely since this isn't a good use-case for it and instead declare the individual document.getElementById('btn-').onclick = function() {
onclick functions for each of the three buttons. Alternatively, and if this was more involved and required a dynamic approach to the onclick handlers, you could create a single function that fires for any of the buttons (likely through a shared class or document.getElementsByTagName()
) and then parses out the number following id="btn-"
to use as the index of the prizes
array to alert()
.
So the Rails has_many
associations sets up a one-to-many association between two models (along with a corresponding belongs_to
) such that given an example of a Chef
model that has_many
Meal
's we could have any number of Meal
's for a given Chef
. When we add :through
along with an intermediary model we are able to create a many-to-many association between the two edge models (Chef
and Meal
) through a middle model (let's call it Recipe
) such that each Chef
has_many Recipes
's and each Meal
also has_many Recipe
's. Thus allowing many Chef
's to have many Meal
's. Similarly has_one :through
establishes another indirect Model relationship through intermediary Models allowing a has_one
associations to be extended for convenience. An example of the model declaration for has_many :through
can be seen in the included file (associations_example.rb
).
In general you should only use either :through
association if you have nested data that is directly related through another model. Use has_one
only if the model has a strict one-to-one relationship with the other model and has_many
if it is one-to-many.
SQL injection is a common application security vulnerability where some data that the app recieves (commonly through a web form or other user submission) is actually executed (typically in an SQL query that takes user input for filtering/srting) as though it were code thus allowing malicious code to be "injected". SQL Injection can steal internal data, crash the app or virtually anything else that's possible in that app's environment. A common example of this would be simply including a ;
in the submitted query to end the current statement and then whatever follows would query directly against the database.
To prevent this in your apps follow these 3 steps:
- Use an server/account that has limited permissions in the database such that only the correct queries can be run and only the correct data can be accessed. Paramterized queries are a good example of this.
- Limit and sanitize user-submitted data. Check for known good data by validating for type, length, format, and range. Avoid disclosing database error information.
- Escape all user-submitted input with
\
A framework is a skeleton of an application where your code defines the operation and customization within that skeleton. The skeleton still has code to link up the parts but the most important work is done by the application. Whereas a library is more akin to a tool that provides specific, well-modularized functions without imposing any structure on the programmer. So a framework such as Angular provides a lot of structure and functionality right away without any customization but it also imposes a certain approach to application building and can prove cumbersome whenever trying to do anything not the "Angular way". On the other hand a library like jQuery does not provide any direct application structure or bootstrap functionality but it does expose tools for a wide variety of front-end tasks that would be more complicated and take more time to accomplish without jQuery. In a way a framework in like the walls and floor plan for your house whereas a library is like the TV within that house.
So in short Big O notation is a way to approximate how the performance/execution/runtime/efficiency of a given function responds to changes in the size of it's input (n
). Given this a Big O notation of O(1)
would indicate that it's not dependent on the input size and always performs at the same regardless of input, O(n)
indiciates that runtime directly and linearly grows with the size of the input (n
). Even worse cases were runtime grows faster-than-linearly to input growth include O(n^2)
and the truly awful factorial O(n!)
(see the graph at http://bigocheatsheet.com/ to illustrate these concepts).
To figure out which notation your algorithm uses:
- So let's say your function has two loops with another one nested inside each, than another three loops not nested: 2N² + 3N
- First, remove anything except the highest single value = 2N²
- Next remove all constants (2 in this case) = N²
- So even though we have two loops with another one nested inside and another three loops not nested the estimated Big O complexity is O(N²) However this assumes that what you have in your loops are simple, direct code. If you have for example filter() inside the loop, you'll have to multiply complexity of the loop by the complexity of the filter() function in the underlying language is using.
The issue lies in the three <div class="tier">
elemtns being float
ed left to align them but the containing <section class="pricing">
not being float
ed. Essentially since float
is designed to break the typical left-to-right top-to-bottom document flow it causes the float
ed element to break out of it's container and forces it as far left/right as possible, when this happens the container element (being still in the document flow) won't wrap the child elemtn since it's float
ing.
To fix this we can either simply add float: left;
to .pricing
so that it is floated as well and will wrap the child .tier
elements. Or, to get around the need to float
in the first-place (full-width display: block;
elements) we could add display: block;
to .tier
so their width
and margin
declarations set up the alignment without forcing all left.