‹ go back

My Experience at HT6.

Published 23 August 2020 at Yours, Kewbish. Also published on Dev.to. 1,729 words. Subscribe via RSS.


This post is unlisted and has been archived. This doesn't represent my best work; please check out the posts listed here instead.

Introduction

A couple hours ago, Hack The 6ix had their closing ceremony, and finished 36 (and a bit-ish) hours of hacking away. Hack The 6ix markets itself as Toronto’s biggest summer hackathon (evidently, it wasn’t in person), and it was an amazing experience! I learned a lot of things regarding JavaScript and OAuth, and did a lot of classic Kewbish speedrunning in the meantime. HT6 is supposed to be 36 hours long, but I happened to be asleep for roundabout 20 hours of the entire thing, so I didn’t have time to complete an elaborate project. That’s the spirit of most hackathons anyhow - short and sweet. I had a lot of fun1, and this blog post’ll be a story of the 16 remaining hours of HT6.

The Project

Before I launch into my chronicle of HT6, I may as well describe my project briefly. In the beginning, it was supposed to be a one-click (but customizable) solution to get Hugo pages on GitHub and published on Netlify as well. The template’d include NetlifyCMS, a bunch of variables that can be tweaked (like all the colours, fonts, base images), and a script to automate deploys. I was supposed to get a login page up with Netlify and GitHub tokens, and then automatically create a repo and OAuth app in GitHub to pass into Netlify for automatic CMS and site generation.

However, it ended up being more on the GitHub side: didn’t have time to integrate the Netlify. In the end, I created a GitHub action to replace all the variables and just have it set up for publication on Netlify without actually creating the site on Netlify for them. The app2 forks a template from my GitHub and runs a Python script to replace the variables. Very hacky, not very stable and probably doesn’t work properly, given that you have to initiate workflows from forked repos manually. But then again: it’s a hackathon project and it’s a feature not a bug.

Day One

HT6 started at 6PM for me (I was eating dinner so I already missed out on like thirty minutes oops), and for the first night, I just spent time reading through GitHub and Netlify docs to obtain various OAuth tokens. I ran into a bunch of issues because I didn’t know how to properly use fetch (if you’re the MLH recruiter reading through my blog, I can assure you I actually do know how to use fetch, I just blanked a bunch of times during the hackathon; I was very tired, please still consider me). First, I messed up the Authorization headers, and then I had a bit of an issue exchanging tokens on the Netlify side. In this respect, I actually think that Netlify’s docs (and forums) were a bit more useful - the GitHub OAuth issue took ages and ages to figure out, while the Netlify one at least showed up on the first page of Google search results.

Day Two

I woke up normally early, but didn’t start working until quite late - 800. (I’d gone to sleep at a reasonable (read: 2130) hour - more time lost!) In the morning, I worked on setting up the customization form, which was challenging but still docs- and Google-able. Then, I started trying to get all the data into a bunch of API requests to start generating the template and hooking it up to GitHub’s and Netlify’s APIs.

The OAuth issue I was talking about earlier was that GitHub’s OAuth web flow doesn’t actually support client-only exchanging for tokens. I’m not sure if this is actually somewhere in the fine print or the OAuth docs that I just missed, but I ended up wasting a lot of time trying to debug a request that wouldn’t work.

Luckily, the power of open source came in clutch: there was a repo for that! prose/gatekeeper provides an easily Heroku-deployable pre-configured app that I could use to exchange for tokens instead! If not for this, I would have wasted infinitely more time trying to set a server up and debugging that instead of properly working with my app (which got scope-chopped as is). I really don’t understand why GitHub won’t let client side apps call the API, and not even making it extremely clear in docs. Very annoying.

Then, after setting that gatekeeper instance up and managing to finally get a token, I started trying to pass the data to GitHub to copy in. The way I approached making a copy of a template was forking the repo from my GitHub, then trying to edit all the variables. By noon, I’d gotten the customization form to properly work, with nicely configured defaults, and I was planning to get the repos variable changing implemented right after lunch.

But then - I didn’t. After lunch, I spent two hours trying to get a file’s contents, replace a variable with the form data, and then POSTing a new page. I managed to get the contents fine, and managed to replace the variables fine. However, I had a lot of issues with trying to POST the new file contents back into the repository. It was returning a 404 not-found error - funny, because I’d already authorized my OAuth app with the scopes needed, according to the docs. After maybe an hour retrying the same request over and over again, I took my token from my app’s storage, and tried making a request with Postman Hoppscotch. The weird thing? It worked fine.

Now, long story short (it was a very long story, mind you), I ended up finally just trying to copy the generated fetch request out of Hoppscotch itself, and there was my issue. (Again, MLH recruiter, I promise I normally remember these things.) I’d forgotten to wrap my body in JSON.stringify. (Feel free to facepalm on my behalf.) With that, it worked, but by then, I’d already moved onto approach #2.

Approach #2 was, instead of getting, replacing, and posting the correct content (variable replaced) back to the GitHub repo, I’d just make a Python script to quickly activate with an Action. I have some experience with this (from my profile README, perhaps), and it was decently easy to implement. By then, I’d already cut the Netlify automation (generating the site, adding the OAuth client ID and secret, and setting build parameters) out from the project scope. Hopefully, I’ll end up being able to work on that in the future.

By then, it was pretty late in the day. I ended up just writing a simple landing page, and cleaning up some of the UI. I removed the Netlify token and authentication logic, and just did some polishing. I wrote a simple README, took a couple screenshots, recorded a demo video, uploaded all my submission data, and sent it off. (By now, it was maybe 2100. Yeah, it was early. Could I have done more? Probably. Did I have the energy to? Probably, but I didn’t really feel like staying up late for a hackathon).

Reflections

You might notice that I didn’t attend any meetups. That was true (I did spend some time in the networking level of the event) - and I probably should have taken more time to explore and network, actually. Hackathons are probably the best way to meet like-minded people outside of proper jobs and conferences. However, if I did go out to a bunch of events, I wouldn’t have any time to work on the hack. That’s an aspect of hackathons that I’m not sure if I like: the balance between networking, events, fun time, and work. I’m not sure whether I’d value a proper project more, or a couple workshops.

And as well, this was the first short-term hackathon that I’ve done. (Does the Dev.to hackathon count?) Anyhow, this was the first very-short-term-panic-speedrun session that I attended, and I’d say it was a pretty good experience. Learning to get a project from 0 to somewhere in a very limited amount of time (which is even more limited when you value sleep instead of projects) is valuable, especially learning how to prioritize features and come up with a plan to work. For me, I’d written down a list of things I needed to do and attached them to time chunks I’d work. Managing that, as well as learning new things, was pretty fun. However, I don’t think I want to constantly do a bunch of hackathons - they promote a very short-term, quick churn, small project mindset that I’d like to turn away from. I’ve done a lot of small projects in the past, and I’d like to get into a bigger, longer-term, more impressive project to dedicate myself to in the future.

Anyhow, here are my three biggest takeaways and things I’d like to do next hackathon:

  • network more! Set aside some time to go around sponsor booths and really connect.
  • limit scope - be realistic with what I can do, and then be more realistic and cut some things.
  • stringify my request bodies. I’m only half joking.

Conclusion

HT6 was a tiring, but engaging hackathon. In the end, I had fun - that’s all that matters.3 Hackathons are really fun, but I think I’m too tired right now to do another 36 / 48 / 72 hour hackathon anytime in the near future. (At least a week, please.)

Right now, I’m going to finally finish up Revshare.js for GitHub, maybe release it, and then actually solidify a project I’d like to work on during school. Oh, and maybe play a little Among Us. Solid game, and I need to recharge from speedrunning a project in effectively 16 hours. Might spend more time working on private repos, so don’t expect to see much activity. We’ll see.


  1. That was a joke; JavaScript and OAuth APIs are very painful to write, debug, and interact with. ↩︎

  2. By the way, the app’s called Obviate (why? I was doing Wordly Wise and had lesson review words stuck in my head.), and if you’ve taken the time to actually read through all these footnotes, you get a special link to my submission↩︎

  3. Shoutout to that guy who gave me career advice, the people who gave me resume help, the mentors who jumped in to help debug the OAuth, and the people in Pwnzorz that provided me with quality background noise and entertainment. ↩︎


‹ go back