Posts from 18 December 2014
-
Today's partner: Jonathan
Today was all about JQuery plugins.
Once we got into the rhythm of writing the html boilerplate and CSS resets and JavaScript namespaces… well, then we had a bunch of trouble trying to write event handlers. God. I don't know how anyone did anything before JQuery, and yet we spent most of the day smashing our heads against JQuery, trying to figure out what it was actually doing. I blame Brendan Eich, frankly. :)
By the end of the day, we had picked up some real speed, but it wasn't nearly as exciting as some other days have been. That said, JQuery plugins probably do more for the web than CSS snake games. I was learning all day, even when we weren't making progress on the specific task in front of us, because we were constantly flipping between APIs, HTML, CSS, and JS/JQ, learning about how they interact. Short of creating specific toys for playing with each component separately (I'm very interested in playing with the Safari inspector's snippets, for instance), there's not a really good way to learn these syntaxes.
From a pedagogical standpoint, then, we return to the problem of unit and integration tests. Today was a lot of integration testing, but our unit tests (building out the basic HTML page, etc) were not well developed enough to truly focus on JQuery. I don't know if there would be a better way to do this—it's possible that, by the time you polished such a curriculum, the technologies of the web would have moved on, and frankly the time (and cost!) of developing such a curriculum is not something you could easily recoup… but it might be fun. That seems to be the main purpose of the web, after all: having fun.
-
Today's partner: Wes
Thank god for Jonathan's CSS lectures.
We skipped the W6D2 content, which was supposed to be on CSS, but last week JT held lectures on CSS at the end of the day each day. Today, we took pre-baked JS solutions for the Tic-Tac-Toe game and Towers of Hanoi and made "visual" versions of them in the browser by using CSS selectors enabled by JQuery.
Holy crap, that paragraph was a mouthful. Basically, instead of using (e.g.) Canvas (which, it turns out, is a difficult term to Google), or a text-only terminal to represent our game state and to select pieces/grid squares, we contrived to capture mouse clicks on a simple webpage, and then to draw game states using document properties of the webpage.
The most important things we learned were the varied uses of JQuery selectors, and how to do basic styling with CSS. By the end of the day, the most we were struggling with were edge-cases in the implementation of our final project, Snake; JQuery and CSS were well under our belts.
I've mentioned before that my memory is one of my best character traits. Well, after this week, I'm realizing that (syntax?) debugging is also another skill I have that others don't always. It's not entirely clear to me whether this is because of my deliberate pace when learning (and the consequent, presumably, deeper understanding that I can achieve), or if I just have more practice/skill than others—or if it's just because I only try the right thing after I've tried all the wrong things. No matter the root cause, I've been happy with my ability to read a stack trace or error message and smash the bug in question, most of the time.
Wes, on the other hand, is much better than I am at identifying a minimum testable product. There were a couple times he had me tie something off and open it in the browser, and while I wasn't immediately certain what he was doing, as soon as we nipped a problem in the bud, I understood. I'd like to add this to my toolbox, too.
Storytime: So it turns out that I'm not very good at games such as chess. My friend tells me that I have a comet-sized ego, and this was nowhere more visible than how I'd play games, especially when I was younger. At the time, I would play a move that could only be considered good if my opponent had no skill whatsoever… but my opponents were never were so bad as I wanted them to be, and inevitably they'd paint the floor with me.
Typically, I want to code for a couple hours, and then run my code and have it be perfect. It is, perhaps, a skill to have the humility to know that you're not as good as you want to be, and (especially when testing carries low overhead) to test your assumptions at good breakpoints. "Measure twice, cut once."
Or, in my case, measure three times, take a break, measure again, and cut once.