WebFund 2015W Lecture 17: Difference between revisions
Created page with "==Video== The video for the lecture given on March 11, 2015 [http://homeostasis.scs.carleton.ca/~soma/webfund-2015w/lectures/comp2406-2015w-lec17-11Mar2015.mp4 is now availab..." |
No edit summary |
||
Line 5: | Line 5: | ||
==Notes== | ==Notes== | ||
<h3>On-screen notes</h3> | |||
<pre> | <pre> | ||
Line 53: | Line 53: | ||
</pre> | </pre> | ||
<h3>Debugging</h3> | |||
If you find yourself saying “It should work, I did everything right”, by definition you are wrong, but do not give up. Debugging is about fixing mental models. Mental models are how we imagine things in the world are. “I type on a keyboard and letters appear” is a mental model. These models are always wrong/incomplete but good ones are useful. When your mental model diverges from your experience, it is common to believe “the experience is broken”, but your mental model is broken. | |||
<strong>Don’t flail</strong> | |||
Flailing: Trying random stuff until you get result you want . | |||
<strong>Do experiment</strong> | |||
First fix the mental model, then fix the problem. The challenge is to generate the right hypothesis. Don’t generate hypothesis purely by searching. | |||
<h3>Steps for debugging</h3> | |||
Observe problems and beware confirmation bias. Pay attention to observations that confirm AND contradict your mental model. Look for outliers. Generate hypotheses via brainstorming, being open to crazy ideas. The first idea you have may not always be the correct one. Explore hypothesss broadly, i.e. Do breadth-first search more than depth first. No hypothesis can be trusted, especially the first one that seems to match. Treat each hypothesis as tentative until you have significant additional evidence. Generate new hypotheses to try and break your candidate solution (fail fast) but move on once it is solved “well enough”. Manage time efficiently when generating new ideas, and not to lose productivity. | |||
<h3>Examples</h3> | |||
“The computer doesn’t turn on, it must be broken.” | |||
<strong>Possible hypothesis:</strong> “The power plug was unplugged.” | |||
“I type on the keyboard but the wrong letters appear.” | |||
<strong>Possible hypothesis:</strong> “The keyboard has been remapped to Dvorak standard, the keyboard is working as intended.” | |||
<h3>Modifying the AJAX notes</h3> | |||
We want to modify the AJAX notes demo to display the contents of the notes on a different view from the list of notes. | |||
How can we do this? Start by modify the title of the note into a link which will change the current view. To do this, we need a link that will not navigate away from the current page. | |||
<code><pre><a href=”#”></a></pre></code> | |||
"#" is normally used to indication a section of the same page. /Main_Page# can send you to top of the page. | |||
In notes.js we can change L10 and L11 from a button to a link: | |||
<code><pre> | |||
‘<a href=”#” class=”editLink”’ + | |||
‘id=”edit’ +i+’”>’+’[edit]</a>’ | |||
</pre></code> | |||
What is the behavior of adding the # or just leaving it blank? | |||
We could look it up, or just quickly try it. With pound, it functions correctly, without pound it doesn't. | |||
Hypothesis, the browser performs a new GET request without the pound, and no new GET request with pound | |||
Results from Browser Inspection | |||
<ul> | |||
<li>With the pound the page isn’t reloaded, and the edit page is rendered.</li> | |||
<li>Without the pound the entire page is reloaded via a GET request.</li> | |||
</ul> | |||
Now, how do we stop the displaying of note content on the page? What line does this? | |||
Removing L12 in notes.js results in the behavior we are looking for. | |||
As you are writing code, it is strongly recommended you test changes as you produce them. In class, we tested a small change but the program didn’t work as expected. Since the JavaScript was client side, the browser indicated an issue on L9 of notes.js where we see we made a syntax mistake. Without testing this change early, future code changes might make finding this bug more difficult. | |||
How do you add a button somewhere? Instead of searching the internet first on how to do this, search the program. The best source of information about a program is the program itself! Where are examples of buttons used in notes.js? L27,L28. | |||
In summary, the process is updating the mental model and working through it. If the program is not working as you expect, stop and adjust the mental model. |
Latest revision as of 17:36, 12 March 2015
Video
The video for the lecture given on March 11, 2015 is now available.
Notes
On-screen notes
Debugging --------- * making a program work - "It *should* work, I did everything right" - if you say this, slap yourself - because you are wrong - do *not* throw up your hands * really debugging is about fixing mental models * mental models are how we imagine things in the world are * they are always wrong, but good ones are useful * when your mental model diverges from your experience... - "it's broken" (no it isn't) - your mental model is broken - first, fix mental model, *then* fix the problem - alternative to flailing (trying random stuff until you get the result you want) - don't flail - *do* experiment - difference between flailing and experimenting is hypotheses - tricky to generate the right hypotheses - you *shouldn't* generate hypotheses purely by searching Steps for debugging * observe problems (beware confirmation bias) - pay attention to observations that contradict your mental model (don't just pay attention to the confirming ones) *look for outliers* * generate hypotheses - initially, "brainstorm" (i.e., be open to crazy ideas) - don't just go with the first one that occurs to you * explore hypotheses broadly - do breadth-first search more than depth-first - be aware that you can't trust any of your hypotheses * don't trust the first hypothesis that seems to match - treat it as tentative until you have significant additional evidence - generate new hypotheses to try and break your candidate solution - (fail fast) * but move on once it is solved "well enough" - know when to stop
Debugging
If you find yourself saying “It should work, I did everything right”, by definition you are wrong, but do not give up. Debugging is about fixing mental models. Mental models are how we imagine things in the world are. “I type on a keyboard and letters appear” is a mental model. These models are always wrong/incomplete but good ones are useful. When your mental model diverges from your experience, it is common to believe “the experience is broken”, but your mental model is broken.
Don’t flail
Flailing: Trying random stuff until you get result you want .
Do experiment
First fix the mental model, then fix the problem. The challenge is to generate the right hypothesis. Don’t generate hypothesis purely by searching.
Steps for debugging
Observe problems and beware confirmation bias. Pay attention to observations that confirm AND contradict your mental model. Look for outliers. Generate hypotheses via brainstorming, being open to crazy ideas. The first idea you have may not always be the correct one. Explore hypothesss broadly, i.e. Do breadth-first search more than depth first. No hypothesis can be trusted, especially the first one that seems to match. Treat each hypothesis as tentative until you have significant additional evidence. Generate new hypotheses to try and break your candidate solution (fail fast) but move on once it is solved “well enough”. Manage time efficiently when generating new ideas, and not to lose productivity.
Examples
“The computer doesn’t turn on, it must be broken.”
Possible hypothesis: “The power plug was unplugged.”
“I type on the keyboard but the wrong letters appear.”
Possible hypothesis: “The keyboard has been remapped to Dvorak standard, the keyboard is working as intended.”
Modifying the AJAX notes
We want to modify the AJAX notes demo to display the contents of the notes on a different view from the list of notes.
How can we do this? Start by modify the title of the note into a link which will change the current view. To do this, we need a link that will not navigate away from the current page.
<a href=”#”></a>
"#" is normally used to indication a section of the same page. /Main_Page# can send you to top of the page.
In notes.js we can change L10 and L11 from a button to a link:
‘<a href=”#” class=”editLink”’ +
‘id=”edit’ +i+’”>’+’[edit]</a>’
What is the behavior of adding the # or just leaving it blank? We could look it up, or just quickly try it. With pound, it functions correctly, without pound it doesn't.
Hypothesis, the browser performs a new GET request without the pound, and no new GET request with pound
Results from Browser Inspection
- With the pound the page isn’t reloaded, and the edit page is rendered.
- Without the pound the entire page is reloaded via a GET request.
Now, how do we stop the displaying of note content on the page? What line does this?
Removing L12 in notes.js results in the behavior we are looking for.
As you are writing code, it is strongly recommended you test changes as you produce them. In class, we tested a small change but the program didn’t work as expected. Since the JavaScript was client side, the browser indicated an issue on L9 of notes.js where we see we made a syntax mistake. Without testing this change early, future code changes might make finding this bug more difficult.
How do you add a button somewhere? Instead of searching the internet first on how to do this, search the program. The best source of information about a program is the program itself! Where are examples of buttons used in notes.js? L27,L28.
In summary, the process is updating the mental model and working through it. If the program is not working as you expect, stop and adjust the mental model.