http://www.youtube.com/watch?v=hQVTIJBZook
Several years ago, Douglas Crockford wrote JavaScript: The Good Parts and has been lecturing about it ever since. The core idea is that JavaScript gets a lot right, but also gets a lot wrong and that if you can train yourself to stay away from the bad parts and to leverage the good parts, you'll be a better coder and be writing better code. (e.g., use === and !== rather than == and !=)
"The Good Parts" has become a standard document for many languages, so you're likely to run across "R: The Good Parts", "Java: The Good Parts" and many other varients.
In this video, Crockford speaks to technicians at Google about his ideas. Crockford is involved in the development of the JavaScript language itself, so some of this will be more technical than what we've conidered in this class, but I think you'll recognize a fair bit of it as central to the way you've been coding.
I hope that one of the things you've learned in this class is that there are many ways of programming, even in a single language for a single task; not all programs are of equal value: some are fragile, some are difficult to understand, some hard to maintain. And sometimes, it's the language that's to blame.
This video offers insight into the corners of Javascript... even the parts that keep the designers of Javascript up at night!
For anyone who really want to understand JavaScript and be a great javascript programmer, I highly recommend the book this is based on... I've read and re-read it several times over the years: http://shop.oreilly.com/product/9780596517748.do
If you want to buy the ebook, I highly recommend buying direct from the publisher, O'Reilly, because of their progressive digital rights management commitment and the fact that you get access to the ebook in any formats you want: pdf, kindle, nook, etc. See their policies at http://shop.oreilly.com/category/ebooks.do
I come back to this book from time to time to remind myself what good writing looks like.
From the Introduction:
"The landscape of programming techniques is enormous, fascinating in its diversity, and still largely unexplored. It is certainly dangerous going, luring the inexperienced programmer into all kinds of confusion, but that only means you should proceed with caution and keep your wits about you. As you learn there will always be new challenges and new territory to explore. Programmers who refuse to keep exploring will stagnate, forget their joy, and get bored with their craft."
https://www.youtube.com/watch?v=taaEzHI9xyY
There's quite a bit of programmer inside jokes that put me off of this video... but there's much good content that's readily understandable, too.
Feedback to Learner 9/25/17 10:21 PM
I added a console.log() call inside the function (a trick mentioned in the debugging videos) to see when/whether your calculate function was being called. I observed that it was, in fact, being called... it just wasn't updating the displayed calculated values. That narrowed it down considerably.
Napkin 09-25-17, 10.21.03 PM.png
You hard-coded the radiusInput value in your calculate function to == 1. You needed to dynamically access that value from the current form field value:
function calculateCircumference() {
console.log("entered calculateCircumference"); // wdoane
var radiusInput = parseInt(document.getElementById("radiusInput").value); // wdoane
Good code formatting habits expose and avoid a great many coding errors. If the indentation doesn't look right, there's probably a missing closing } ) or ], for example.
Use a code formatter to help you get well-formatted code and try to make paying careful attention to code format a habit.
chapter 3
First, none of those errors are in your code (notice the names of the source code files). It's not uncommon for there to be errors when loading pages, especially locally, due to security restrictions. Ignore the errors about other people's code as much as you can :)
Second, when you're setting a equal to b, you want to use one equal sign: var x = 5;
In your code, you're using === everywhere... a === b is a question: is a the same value as b and are a and b of the same datatype? x === 5 returns a TRUE, FALSE, or one of the undefined values.
e.g.: listItem === "item" + i; // should be one =
Once you've sorted that out, you'll be able to
document.getElementById(listItem).innerHTML = document.getElementById('toolbox').value;
chapter 4
First, none of those errors are in your code (notice the names of the source code files). It's not uncommon for there to be errors when loading pages, especially locally, due to security restrictions. Ignore the errors about other people's code as much as you can :)
Second, when you're setting a equal to b, you want to use one equal sign: var x = 5;
In your code, you're using === everywhere... a === b is a question: is a the same value as b and are a and b of the same datatype? x === 5 returns a TRUE, FALSE, or one of the undefined values.
e.g.: listItem === "item" + i; // should be one =
Once you've sorted that out, you'll be able to
document.getElementById(listItem).innerHTML = document.getElementById('toolbox').value;
Being able to debug your code in any programming language is an important skill. Here are some pointers about debugging JavaScript in your Web browser.
Some of these videos show me debugging code from later in the course... so you may want to keep coming back to these as the context becomes more obvious.
Javascript code is just plain text. It can live inside of HTML pages for simple scripts. But for more complicated scripts, you'll usually want to have your Javascript code in its own .js file and link to it using the script tag with an src attribute. This allows coders to write libraries of useful Javascript code that can be easily distributed as .js files and incorporated into your pages with the script tag. Modernizr and JQuery are examples of this practice.
Javascript in the browser is used to add behavior to otherwise static webpages: HTML is used to describe the structure; CSS is used to describe the look and feel; Javascript is used to describe the behavior of page elements.
Any Javascript code at the "top level" of your script -- that is, that is written in a script tag with further encapsulation -- is executed as soon as your page is read in to the browser's memory and parsed. That's often undesirable... you want to be able to describe behaviors that will happen at some future time while the user interacts with the page, often in response to some event: the user clicked a button, the user moved the mouse over a certain element, a given period of time has elapsed, the user pressed a key, the user entered a form field, the user left a form field, and so on.
Functions provide one way of encapsulating your code. Functions are parsed as the page is read in to the browser, but they're not evaluated (executed) until the function is later called, much like the document.write() function is defined, but does nothing until you actually invoke the function.
Functions can either return a value or return nothing and just do something (write to the document's structure, e.g.). I tend to prefer the former style of programming. Consider these two slightly different ways of coding a function:
function myFunc(x) { document.write(x + x); } myFunc(5)
With myFunc(), I can get the desired output, but that's all I can do. Now consider:
function myFunc2(x) { return(x + x); } document.write(myFunc2(5));
By having myFunc2() return a value, rather that writing it out directly, I can still write out the value, when I want... but I can also use the returned value and combine it with other functions, such as +:
function myFunc2(x) { return(x + x); } document.write(myFunc2(5) + 1);
You'll see both styles introduced this week and experience the pros and cons of each for yourself.
http://javascript.crockford.com/code.html
Every programming language has associated idioms and coding styles that programmers using that language use and expect others to use. Part of becoming proficient in any language is learning these idioms.
A sure sign of someone who doesn't "get" Java is a Java program written as if it were a C++ program.
The same has been said for any pair of languages: lisp and C; Ruby and Python; C and R.
Doug Crockford is one of the designers of Javascript. I'll be turning to his writings often in this course and you'll be a better programmer, if you try to understand what he offers. Granted, some of it is nuanced and intended for advanced programming activity, but there's much that any level programmer can learn.
Object and Array are closely related in JavaScript... In fact, an Array *IS* an Object, but not all Objects are Arrays. An Array is a way of storing key-value pairs where all the keys are integers, starting with zero. The keys in an Array are usually left unstated in the code, but they're there:
var myArray = ["a", "b", "c"];
console.log(myArray[1]); // "b"
An Object is a a way of storing key-value pairs where the key can be a string:
var myObject = {first: "Wil", last: "Doane", profession: "Professor"};
console.log(myObject.last); // "Doane"
but because Objects and Arrays are really very closely related, I could also access the last name element using bracket notation:
console.log(myObject['last']); // "Doane"
Confusingly, Arrays can have Objects in them and Objects can have Arrays in them:
var myArrayOfObjects = [ {}, {}, {} ]; // an Array of three (empty) Objects
var myObjectOfArrays = { one: [ ], two: [ ], three: [ ] }; // an Object with three (empty) Arrays
There are no limits on how you can compose your data. You can have an Array that has more Arrays within it that have more Arrays in them that...... and the same is true for Objects (that have more Objects in them, and so on...).
Chapter 5
Stubbing is a method of writing method stubs: the bare minimum that will let the page load (or in Java, allow the code to be compiled). You use this method when the code within the method is too complex to write at the moment or when you're just testing that methods are getting called.
function doesSomething() {
console.log("entering doesSomething");
console.log("... doing something...");
console.log("exiting doesSomething");
}
You may see the alert() method used to generate output... I prefer the more subtle console.log() so that the output doesn't interfere with the operation of the page itself. For example, if you're trying to test mouse hovering or clicking behavior... that's difficult to do, when a modal dialog box keeps popping up and you have to move the mouse over to it in order to click OK to dismiss the dialog. See the "Debugging in JavaScript" videos (in the left hand nav) for more information about using the JavaScript console.
Stubbing is a practice you can use to outline a set of methods you intend to write, just to make sure it all fits together... then worry about the details of the code within the stubs.
Programmers will also say "stub out your code", meaning "write the skeleton".
If the function must return a value, it's common to hard code the return value initially. For example:
function isEmailAddressValid() {
console.log("entering isEmailAddressValid");
return true;
}
function getNumUsers() {
console.log("entering getNumUsers");
return 1;
}
Especially when writing event-driven JavaScript, you often find yourself needing to write a function to handle clicks, or to handle page load, or to handle.... By writing stubs with simple one-line console.log() messages, you can see whether even the messages are getting triggered at the right times before committing yourself to writing the entire method.
A quick stub just to be sure what events are being triggered can be a lifesaver!
document.getElementById("button").onclick = sendFlowers;
function sendFlowers(evt) {
// this is a stub... it obviously does not send flowers, yet
console.log("sendFlowers() called");
}
Now, you can test whether clicking the button calls the intended function or not.
Chapter 6
http://diveintohtml5.info/forms.html
Chapter 7
Because JS is a Prototypal language, it's easy to extend the capabilities of existing classes. Let's try extending the String class.
Try entering the following into your browser's JavaScript Console:
String.prototype.doh = function() { return(this + " DOH!"); }
Then you should be able to do the following, too:
"Bart".doh()
I'm fond of the DIVE INTO... series. However, be aware that the cutting-edge nature of these HTML5 enhancements means that some web browsers will not support certain HTML5-specific features, yet. Try them out. If they don't work in your browser, try a couple of alternative browsers. Otherwise, it's likely a feature that's not supported yet. (The color picker comes to mind.)
You're very close... you need to add event listeners for when a date (or prev or next or close) are clicked. See the lines in orbits.js that end with the comment // wdoane
Chapter 8
Often, the primary approach to understanding someone else's (and possibly even your own) code is to see it fail, check the values and data types of variables, check your assumptions about what you thought the values and data types were, make an adjustment, repeat. It's a little like trying to open a puzzle box: does it slide this way? that way? oh, it twists!
Object and Array are closely related in JavaScript... In fact, an Array *IS* an Object, but not all Objects are Arrays. An Array is a way of storing key-value pairs where all the keys are integers, starting with zero. The keys in an Array are usually left unstated in the code, but they're there:
var myArray = ["a", "b", "c"];
console.log(myArray[1]); // "b"
An Object is a a way of storing key-value pairs where the key can be a string:
var myObject = {first: "Wil", last: "Doane", profession: "Professor"};
console.log(myObject.last); // "Doane"
but because Objects and Arrays are really very closely related, I could also access the last name element using bracket notation:
console.log(myObject['last']); // "Doane"
Confusingly, Arrays can have Objects in them and Objects can have Arrays in them:
var myArrayOfObjects = [ {}, {}, {} ]; // an Array of three (empty) Objects
var myObjectOfArrays = { one: [ ], two: [ ], three: [ ] }; // an Object with three (empty) Arrays
There are no limits on how you can compose your data. You can have an Array that has more Arrays within it that have more Arrays in them that...... and the same is true for Objects (that have more Objects in them, and so on...).
In http://www.screencast.com/t/3ni0iJ4GWA at about 04:40, you say "I don't see my string happening...", but I'm not sure what that means.
listitems is an array of LI elements. Notice that there's a disclosure triangle to the left of it in the debugger... you can click that to show more details about the items in the array. Each of the LI elements has a value/innerHTML/name/id/whatever that will be the name of that item.
You also had console.log appearing AFTER return statements. Once JS hit a return, nothing further in that function is evaluated... the function immediately returns. See for example http://www.screencast.com/t/3ni0iJ4GWA at 01:11 lines 25, 26.
chapter 9
chapter 10
chapter 12
Notice the CHAPTERS list on the main jQuery page:
How to prepare for a JS interview:
https://medium.freecodecamp.org/the-definitive-javascript-handbook-for-a-developer-interview-44ffc6aeb54e
Note to self: all my class submissions are on screencast.com with a username of cherrmann@osc.state.ny.us and denver x 2.