var week = 5, day = 5;
JavaScript: Asynchronous Single-threaded Programming Solutionsâ„¢
So thus far our forray into JavaScript has been comprised of repeating a large portion of the Ruby exercises we did in weeks 1 and 2, but you know, in JS. We did a JS console version of Towers of Hanoi and Tic Tac Toe. We did all the fun recursive problems from w1d4 again: recursive sum, recursive fibonacci, recursive make change, etc.
Today my partner and I finished everything early, and there was no bonus, so we went back and started the bonus project from the previous day which is a game variably called "Reversi", "Othello", or "Morocco". The app version on my phone is a favorite of mine for passing the time, so I was excited to work on this game. We didn't get too far in the 40 minutes we had left, but as we worked on the more basic setup aspects of the game we talked about what we expected would give us the most trouble down the road. We agreed that the most difficult part of the logic would likely be determining the valid moves and that our implementation would likely ened up looking a lot like the Queen class in chess which inherited most of its basic functionality from the SlidingPiece class. We assumed we would end up with an array of 8 directional deltas that we use to check each direction from the starting position for valid moves, checking each potential endpoint with an #onBoard method and an #empty method that makes sure the position is valid.
The most difficult part of the day (and I'm given to understand it's also one of the more difficult aspects of JS overall) was keeping in mind the current scope when invoking keyword this and remembering to properly bind functions used in callbacks or otherwise sent as arguments of other functions in order to keep this in the intended scope. The second most difficult part was getting our chronologically dependent methods to get called in the correct order via callbacks. This is difficult because, as we all know, JavaScript is (say it with me now) single-threaded asynchronous. Meaning when you ask for user input, the program doesn't just sit and wait for the input, it keeps reading and executing code. So if some portion of the program is dependent on that user input, you have to force JS to wait for it by passing the dependent portion as a callback. While callbacks make complete sense once you get the hang of them, they aren't particularly intuitive at the outset, or at least they weren't for me.
So far we've just been using Node.js in the console and haven't had to think about the DOM or accessing elements by tags, classes, or ids. Monday we're making another console game, so I guess we get a little more time before we get thrown in that box.
