Daily Learning Notes for April 12, 2017

Yesterday I added new events and logic into my mob coding app for creating, editing, and forking Gists with the GitHub API. It’s mostly working! But I ran into an error when forking a gist, testing the feature by logging into two different GitHub accounts. So that’s where I’m starting this morning. I have until 11am to work on this, and I’m really hoping I can finish this feature today!

Goals for today

  • Figure out what’s causing that 422 “Unprocessable Entity” error from GitHub, and hopefully fix it!
  • Display a list of links to the gists created by the app, or at least show the latest gist so users can bookmark it
  • Actually commit the content of the code editor into the gists!
  • If I finish that early, I guess I can start fixing up the app UI a bit, like making the code editor take up more of the screen and other little fixes like that.

Real-time notes

8:01am: I figured since I’ve been getting back into the habit of writing while I’m learning/working, I may as well include the timestamps again! I found that helpful when I had a good blogging streak going last year. Anyway, looking at this 422 “Unprocessable Entity” error again, my first guess is that maybe I just didn’t give GitHub enough time to create the forked gist before I edited it! So first I’ll just try another test, but slower this time. This workflow with logging into two GitHub accounts just to test my app is going to be pretty annoying… OK, here we go.

8:14am: It works just fine! And that’s with giving each user only 30 seconds per turn, which I imagine is the shortest turn that could possibly work anyhow. Woohoo, so I’m done! Sort of. I forgot something else I should add to my goals for today: actually commit the content of the code editor into the gists!

First I’ll start by listing the gist URLs in the UI so it will be a bit easier to test. I also just realized I should be grabbing the “html_url” property from GitHub’s response, not the “url” property, which points to the API so it just returns some JSON data instead of a webpage.

8:35am: I changed my mind: I don’t need a list of gists! I’ll just display the most recent one, since that’s all I really need, and it’ll be easier to sync the UI between all the clients.

9:00am: Testing is going very slowly! But it works well enough now. I noticed a couple other bugs, but I’m just going to move on for right now, haha. Next up: committing the actual content of the code editor into the gists!

9:17am: Interesting. It works, but I think it might be attributing the updates to the wrong person! I need to double check this again now.

9:25am: There is something very wrong here! What is this bug?! Not only are the updates being misattributed, but it looks like the forks and edits are being made at the wrong time! Hmmm. Oh, is it because of the delay between forking and editing, just due to the time it takes to wait for GitHub’s response to my requests? That might be it. But then there was also that weird bug I found previously where the game changed the turn too early. I wonder if that’s related. Clearly I need a better way to test this stuff!

Time for a quick break first, though. I need to stretch my legs.

9:50am: And now I’m back. Not sure why that break took so long! Guess I got distracted. OK, where did I leave off? Right, testing… Maybe I can just get rid of a bunch of the console.log statements that I don’t really need to look at right now, and add timestamps to the important log messages.

10:28am: I honestly have no idea how so much time has already passed! I must be experiencing some microsleep. Well, I think I identified a pretty important bug: the server sends out the “turnChange” event every time a new user connects, so all the other players can update their views. That logic might be wrong right there. But in addition to that, when the client-side handleTurnChange function is triggered by that event, I’m calling the functions to fork and/or edit the gist, assuming that those functions would only get called when the turn actually changes! But I made an incorrect assumption, because my functions are doing more than they’re supposed to now, or they’re inaccurately named!

To fix this, I might have to do a lot of refactoring. I only have 30 minutes left to work on this today, though. (Unless I either finish my other work early, or I decide to procrastinate more on all my other tasks today.) I’ll try scribbling on paper a bit to see if that can get my brain unstuck…

10:35am: I have an idea for the quickest fix, just to see if it works: I can split this messy function into two, each one triggered by a different event, and just leave some duplicate code for now until I get a chance to clean it up later.

10:57am: I’m not seeing the bug indicating that anything’s happening at the wrong time, but I have definitely confirmed that the forking/editing is backwards!

Here’s the logic flow that I need:

  1. Create a new gist on behalf of the first user
  2. At the end of the turn, edit that gist on behalf of the first user.
  3. At the end of every subsequent turn, fork and edit the previous gist on behalf of the player whose turn just ended.

That’s why I’m doing wrong: the wrong user is forking the gist! I just need to switch the order.

11:10am: Got that “Unprocessable Entity” error again, and I see why: my check for the first turn change is totally wrong, so it’s trying to fork the users’s own repo, which isn’t allowed. How can I fix this?

11:29am: Fixed! I just added a Boolean value for now that changes after the first edit is made to the gist. (I’m sure this fix will cause all sorts of other unforseen bugs later though. It’s meant to be temporary.) And I confirmed another bug: during the delay between forking and editing the gist on each turn, if the other player types within that window of a couple seconds, their changes get included with the previous player’s turn!

I’m already 30 minutes overtime here, but when I get back to this later, I know that in order to fix this, I need to save a snapshot of the current editor content into a temporary variable or something instead of pulling directly from editor.getValue()!