DougM to convert these notes into separate issues, as needed

[intuedge]

DougM to convert these notes into separate issues, or make a pull req, after the inaugural workshop (and post-workshop update).

These notes were extracted from multi-item "issues" that were closed once a single item had been handled.

Lesson 2:

• Code explication at the bottom of the page is good. We should mention it up top.
• How to comment in js?
• "Get the value" of draw() "and execute it with the list" is hard to understand without functional thinking, and a basic understanding of an interpreted language.
• typos -- parentheses (plural) and its (possessive pronoun)

Lesson 2 Play Time:

• Level of handholding in the lesson contrasts starkly with the absence of handholding in the exercises:
• how to comment (mechanically, and philosophically)
• how do I figure out what colors are valid
• have to figure out to add another pixel hash to the snake array to make it "longer" (or did I just make it wider? -- very little directionality implied by the data structure)
• not very obvious to a noob that you can add more objects to the array to be drawn; if they copy and modify the original code to create a parallel set of commands for (e.g.) an apple, the snake seems to disappear from the canvas.
• Explain camelCase convention?
• Are you expecting them to open up and interpret chunk.js? Why all-caps in code?
• Is there some habit about commenting a code file to say what (plus when and who) that we should be encouraging?

Lesson 3:

• Do they empty snake.js and start with a clean file?
• The added object from lesson 2 play time is not carried forward.
• Might ask them what are the largest and smallest values for a "pixel" to be drawn.
• Somewhat confusing to draw a box with many pixels and call it a pixel.

Lesson 4:

• Definitely need to keep the Lesson 3 snake.js code and extend it for this round. Must save .js and refresh browser before using console.
• typos: called; oldSegment's (possessive)
• Why create a newSnake? Counter-intuitive to moving the old snake. Why not return [newSegment];? Have to do snake = moveSnake(snake); to move the snake, so the naming is confusing, too. snake is actually snakePosition, so overly simplified naming piles on unnecessary cognitive dissonance for the noob.
• If chunk.js is functioning as a game engine, then it makes sense to separately call:

  snake = moveSnake(snake); // update cycle
  drawSnake(snake); // draw cycle
  but that's an advanced concept, and otherwise my lazy ass wants to go straight to:
  drawSnake(moveSnake(snake));
  which of course doesn't work because moveSnake(); doesn't move the snake.

• I think snakePosition = movePosition(snakePosition); is a bit easier to grasp, but I could be totally wrong.

overall -- just do separate PRs for typos (one per file?)

[zspencer]

I'd take pull request that is typo fixes only; but for each independent question/desired change (i.e. "moveSnake could be movePosition") I'd prefer a single pull request or issue.

[intuedge]

Understood. What about suggested wording changes (if any) on the explanatory content? More like an issue (one PR per change), or more like a typo (one PR per file)?

[zspencer]

Wording changes to improve clarity are issues.

If one thing can be done independently of other changes it should be its own issue.
If multiple things can be done with 100% confidence it's useful (typo fixes, for instance) then feel free to submit them as a group.

A single PR may address multiple issues (for instance I may collect a few 'snakes should be green not blue' issues into a single PR where I grep through the code and fix them all.)

Smaller changes are easy to integrate.

Zee

[intuedge]

Clear. Thanks.

Congrats again on the first workshop. Looking forward to the notes.

DougM

[zassmin]

@intuedge are these addressed? I think we've covered some of these in separate issues.

[intuedge]

@zassmin and @zspencer is there a quick way to get a sense of what was updated after the workshop? I'll make time this week to review and then clean this up.