Useful resources: https://help.github.com/articles/set-up-git/
Step 1. Check for git on your machine:
In terminal
$ which git
if you get something along the lines of /usr/local/bin/git
you have git,
Useful resources: https://help.github.com/articles/set-up-git/
Step 1. Check for git on your machine:
In terminal
$ which git
if you get something along the lines of /usr/local/bin/git
you have git,
based off a simple side project menu preferences the WIP git repo
The following is adapted from my mentor, Elise Fitzgerald!
#Intro to jQuery Library
jQuery is a JavaScript library. jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers.
There is also another extension library called jQuery UI that provides some nice effects and methods for enhanced user experiences.
I have this property… should it be in the constructor or the prototype?
think of the constructor as the initialize function in ruby
the constructor should contain only things **unique **to the instance of the object, such as properties (aka attributes, similar to instance variables in ruby)
it is only executed upon the creation of the object, if you add methods to the constructor after the object is created, the already created object will not have access to those methods
# layout.erb
<html>
<head>
<title>My Site</title>
</head>
<body>
<%= yield %>
</body>
If you ever need to store something like a phone number, a zip code, essentially anything with the possibility of having a leading 0 such as an account number ALWAYS STORE THIS AS A STRING, if you store it as an integer 02143
will become 2143
In general you will see a common theme of doing things both on the database level and the model level to accomplish things such as validations and associations, this leads to extra safeguards and also
recall that SQL is how we talk to databases, if something does not get saved to the database due to some erroneous attempt (such as forgetting something that you put a NULL: false constraint on, the record will not be saved BUT the database may not tell us anything informative about what happened so we might assume things are A-ok
keep in mind that we have more specificity with Model level validations than we do with Database level, sometimes we will only be able to do specific validations on the model level such as having a ver
class ReviewsController < ApplicationController
def index
@product = Product.find(params[:product_id])
@reviews = @product.reviews
end
def new
@product = Product.find(params[:product_id])
@review = Review.new
Javascript can only execute one thing at a time, if there is a process that is time costly like communicating with a database, we have ways to handle these processes asynchronously
callback pattern - if we want to ensure a particular sequence of execution, traditionally one way we do this is via callbacks
since functions can be passed around as arguments, callbacks involve taking another funciton as an argument so that the callback is only executed after the asynchronous task/function completes
this works fine for simple callbacks, but if there is a series of events you need to happen you encounter callback hell , aka Pyramid of Doom aka spaghetti code
class ReviewsController < ApplicationController
def index
# use the product id from params to find the product of interest, the key of the params hash can always be seen in the dynamic portion of the URI via rake routes
@product = Product.find(params[:product_id])
@reviews = @product.reviews
end
def new
@product = Product.find(params[:product_id])