I have a lot to catch up on, but for now here’s the bare minimum context for today’s blog post: I’ve been working on building a mob coding app, and now I want to get back into publishing my notes on my blog, because I’m asking all my students/teammates in this programming (un)bootcamp to publish a daily blog post about what they’ve learned as well! I need to eat my own dogfood here, haha.
Starting my day with this question: What should I work on next? I feel so conflicted and anxious right now. (And sleepy.)
OK, I walked away from this for a bit, got myself some coffee, scribbled some notes on paper, and now I actually do feel a bit better again. Phew!
Goal for today: See if I can commit users’ code to a GitHub gist using the GitHub API and have each subsequent user create a fork of the previous gist.
This is the simplest workflow I can think of for saving version history using the GitHub API. I don’t know if it’s the right solution, but when I worried about making the “right” solution immediately, I got really anxious because I just don’t have enough information to know what the “right” solution is! When I’m stuck like this, it usually helps to just pick one thing and try it, even if I throw it out later. I feel better when I think about it as an experiment – something temporary, something that can fail with no serious consequences. It takes off the pressure and reminds me that solving open-ended problems and building new things is a messy process. When I sat down to start working today, I guess my unspoken goal was to get closer to finishing this mob coding app. But that is not my goal! My goal is to learn more through deliberate practice. It’s OK if I don’t get any closer to finishing the app today, as long as I learn something new and I make an honest effort to push the boundaries of my understanding. That feels doable – and much less scary. Phew, I thought I was about to have a panic attack and it’s not even 9am yet! Crisis averted. (Side note: drinking a little coffee right now is also helping a lot with making me feel more motivated and alert right now. Yay, caffeine!)
I’m starting a bit slower today, but that’s OK. After the weekend (and the first day of my experimental programming unbootcamp), I completely forgot where I left off with this project. So here I am reminding myself that it’s OK if I start off slow. I’ll gain momentum throughout the week. The important thing is to keep trying, to not give up just because I feel uncomfortable right now. With that out of the way, now maybe I can focus!
First round of questions:
- How do I create a new GitHub gist using the GitHub API?
- What permissions do I need to request from the user?
- How do I create a fork with new changes/commits based on an existing gist using the GitHub API?
- How should I keep track of the latest gist and share that link with all the users within the mob coding game?
Notes on gists:
-
GitHub’s documentation on gists says they support public gists, “secret” gists (not searchable), and anonymous gists. (I’d love to take advantage of the anonymous option for users who don’t have a GitHub account!)
-
Every gist is actually a repository! They can be downloaded, forked, or cloned, and they can include multiple files!
-
The “revisions tab” on each gist shows its complete version history!
-
Unlike normal repositories, gists can be embedded in other websites to display code snippets. (Maybe I can make use of this feature too!)
-
It looks like the only missing feature is the ability to assign a permalink to a project/coding session.
-
On the other hand, gists have an advantage over normal repos for my mob coding app: users who play the mob coding game a lot might not want to pollute their GitHub account with lots of repos! But gists, on the other hand, are meant to be more temporary / small snippets, and they’re kept separate from a user’s list of repos. That lines up more with the purpose of this app!
-
The GitHub Gists API lets me read and create public gists for anonymous users without authentication, but to read or write gists on a user’s behalf, I need to request the “gist” OAuth scope.
-
There’s also a Gist Comments API – good to know!
-
To create a gist with the GitHub API, I can just make a POST request to their /gists API endpoint with some JSON data for the contents of each file. I can also edit a gist and fork a gist just as easily.
Time to test this out! For now, let’s just say that whoever’s the first user to join the mob coding game is the one that creates the initial gist for that session. I’ll have to see how I can run that code on the server.
Oh, and before I start, I need to create a new branch in Git! I guess I’ll call it gists – short and sweet, since it’s my very first attempt at using gists with an app.
I just thought of a very important question: should the server create the GitHub gist for the user, or should the client create it? What are the pros and cons of each approach?
If the server does it, I need access to the client’s OAuth token… Is it a good idea to save the token on the server? How would this even work? Hmm.
After a little research, it looks like people do store tokens in databases sometimes, as well as in cookies or local storage on the client side. I’m purposefully ignoring all security issues right now though, haha. Even so, I need to sketch this out on paper a bit…
The server controls the turns in the game (to prevent cheating!), but there’s no way to prevent users from forking or editing gists on their own outside of the game. And that shouldn’t matter, anyway. OK, so right now I guess it doesn’t matter whether I create the gists on the client side or on the server side. I’ll just try to get something working for now, and look into how to do it securely later.
Stuff to read later:
OK, I’m letting myself get stuck on this for too long. Took a break to chat with a coworking friend. I need to actually write some code at some point this morning though! I’ll just see first if I’m even able to make a POST request to GitHub’s API with AJAX on the client side. I also just realized that I don’t even know how to pass the access token in my POST request… I didn’t see any mention of that in their API docs… I wonder how it works! Oh OK, I should send it with the “Authorization” header like I did when I tested it with cURL the other day. I wonder if it’ll work as a URL parameter too.
Bugs, bugs, more bugs!
-
First problem: I accidentally requested a permissions scope of “gists” when it’s actually “gist”, oops! Why didn’t I realize that sooner?!
-
Second problem: according to the “X-Accepted-OAuth-Scope” header, I need to request the “repo” scope in order to create a new gist. But the GitHub Gists API doesn’t mention that at all! Weird! I guess the “gist” scope is only good for editing existing gists?
-
Still stuck! Even after getting the full “repo” permissions scope, I’m getting a 404 “Not Found” response from the GitHub API. What’s strange is that even a simple GET request to
https://api.github.com/gists/gives the same error! But I can accesshttps://api.github.com/gists/publicjust fine, and I can accesshttps://api.github.com/users/LearningNerd/gistsjust fine. -
I was able to edit my own gist by sending a POST request to a gist I had created previously at
https://api.github.com/gists/5614826e7c991d0b29ca74905f780a4fand that worked fine! This is pretty weird. -
Whoa, now it works?! I just tried again and I didn’t do anything different, and this time it worked! I wonder why… This is what worked:
curl -i -H ‘Authorization: token MY-TOKEN-WAS-HERE’ -d ‘{“description”: “a brand new test gist!”, “public”: true, “files”: {“newtest.md”: {“content”: “This is ANOTHER test gist made with the GitHub Gists API via a client-side POST request using AJAX!”}}}’ https://api.github.com/gists
- Oh, what?! No way! It looks like the whole problem was caused by me accidentally including a trailing slash at the end of the API. Haha, whoops! Now it works! I’ll test it in my code again now too…. Yup, it works now!
And now it’s already time for me to stop my morning work session and switch to some other projects that I really need to work on today. I wish I could just work on this the entire day, though! Argh, I made so little progress! Oh well, I know that’s how it goes. At least I learned something.
Lesson learned today: when debugging, check thouroughly for all possible typos before trying anything else! And remember that the GitHub API endpoints don’t have a trailing slash!