< More Posts
Published 16 August 2020 at Yours, Kewbish. 1388 words. Subscribe via RSS.
Also published on Dev.to.
And finally, after one and a half-ish months, I’m done with CS50! From the very first blog post till now, I’ve been enjoying documenting my progress and learning, and it’ll be a fun read to reference back to in a couple of years to see how I’ve built off this knowledge.1 This last week, I’ve been working on my final project, and here, I’ll be going through that, along with my thoughts and reflections on the course and experience as a whole.
My final project was a Chrome extension that added Web Monetization capabilities to GitHub. For context, Web Monetization is a proposed browser API that’ll make it easy for developers and content creators to monetize their browser work. It works by streaming small micropayments over time to a payment pointer, specified by the creator. This pointer is located in a meta tag with the name
monetization, and while this API hasn’t officially been implemented in any major browsers, you can read more about it here.
Recently, there was also a Dev.to hackathon where Coil, Creative Commons, and Mozilla were calling for project proposals for their grants. I participated in this hackathon, and my project was an implementation of revenue sharing with payment pointers. Essentially, this implemented a custom HTML tag that had an attribute of an array of payment pointers, and my library, revshare.js made it easy for devs to add a probabilistic pointer choice for the payments to be streamed to.
Fast forward a couple months - to this week, in fact. I was looking for a CS50 project, and after brainstorming a couple random projects, a colleague suggested ‘Revshare.js for GitHub’. I immediately liked the idea - it was relatively simple to implement, would teach me more about GitHub’s GraphQL API and Chrome extensions, and I saw it as a logical extension of the earlier hackathon project. So with that - I jumped into creating the extension.
The extension’s pretty simple, but has three-ish main features.
One, it goes through the repository (through a check to see if you’re on a github.com/*/* domain) and looks for a Sponsor button through some questionably implemented DOM checks. If found, it looks for the link to the fragment HTML, which I then scrape and select all the links, through more sketchy queries. Once I’ve retrieved all the links, I check if each link begins with a dollar sign, which is the syntax for a payment pointer. If that pointer’s found, or if there are multiples, it chooses one randomly to add to the head of the page itself. With Coil, the extension then begins streaming payments to the payment pointer.
Two, it adds a
starsOnly flag to Chrome’s storage. If selected, it’ll check that the repository is starred before inserting the monetization tag. If it’s selected, and the repo isn’t starred, then too bad - the repo owner won’t be able to get any monetization. This is accomplished through some quite questionable queries to the GitHub links at the top of each repo.
Three, it adds a bunch of checks through each repository’s dependencies, looking for the same funding links and $-indicated wallet pointers. If they’re found, the extension performs another random selection between the existing repository funding pointer and these new links. It’s a roughly 50/50 split between repository creator / owner (i.e. original funding pointer from repository itself) and a random dependency chosen from the list of valid wallet pointers found in each dependency’s links. This is pretty cool, because a lot of repositories and dependencies are built for dev-only use, and they don’t get a lot of love from supporters. We can even look at stars between a popular Python web microframework Flask and its dependency Jinja. Flask has 51.7k stars, and Jinja a meagre 7.2k in comparison. Given a similar percentage of stargazers / sponsors, Jinja would get a lot less funding - though both libraries are equally important2
I found it really fun to learn a bit more JS (it’s not as painful as it’s made out to be, used in the appropriate contexts) and do a bit of DOM engineering. I was very intrigued at the little performance things that GitHub added, like only loading funding links when the button is hovered over, and loading both starred/unstarred versions of the top bar and switching between them client side (I believe). These little tricks were definitely annoying, but in the end, they probably make the GitHub website a ton faster, and hey, I eventually found ways around them. (And in the future, I’ll be sure to use the same bypassing techniques I used, like getting fragment URLs instead of trying to force a button click, when I’m trying to manipulate something else.)
I found the first few weeks of CS50 extremely informative. Going from someone who’d basically only touched Python, it was sometimes difficult to understand lower-level details like pointers and such, but (while I’m still an extreme beginner and probably can’t do much more complicated than Problem Set 5) it was great for what I was taking the course for: data structures, algorithms, and more low level knowledge.
However, I found the latter half of CS50 kind of glossed over a bunch of technologies instead of really diving deep into one for the entire time. I wouldn’t have minded as much if it was just C / Python and we went equally (or not) deep into both. The way they have it now, we’re just speedrunning a bunch of things that are slightly related but not entirely, and slapping them all together. I would have loved to spend more time with SQL and Flask - but then again, CS50 is an intro to programming, not a deep dive into whatever.
I guess there wasn’t that much of an overlap between my initial purpose for taking CS50 and what it ended up being. It might have been due to the fact that I’ve already done Python and Web, really, but I ended up just speedrunning most of the latter half of the course. I would have enjoyed going into more DSA in C, for example, but that wouldn’t have really helped newbie programmers, I suppose.
In the end, if you gave me a magic time machine, I would still have taken CS50, but maybe dropped after the first few weeks. I found it a great experience, and nothing’s perfect. Taking a Python DSA (or even just C DSA) course, and then taking a few weeks to do a proper web project and learn SQL / Flask might have been a more beneficial route for me, but CS50 also gave me a lot of motivation. Look, a shiny Harvard certificate. Maybe the feeling of actually taking a class and getting that Harvard clickbait helped me through it. I don’t know - but I’ll be doing more research and more carefully considering any MOOCs / courses I take in the future.
As I write this, I realize that I only have two (three? four? depends on when the school system decides to start, but so far I think it’s three?) weeks of summer left. CS50 + summer courses + random projects made the time pass a lot quicker than I thought it did, and as I look back, I don’t think I took that much time for ‘relaxation’ really. Then again, coding is kind of my ‘relaxation’ thing, so maybe in a way I’ve done a lot more relaxation than it looks like I have.
I’m looking forward to Hack the 6ix in a week, and then writing and finishing up some summer work for school for the rest of summer. Maybe I’ll release Revshare for GitHub on the Extension store if I feel like it, and maybe I’ll work on starting a bigger project. One thing at a time though - time to add CS50 to my list of Licenses and Certifications on LinkedIn!
Which hopefully, I have. But then again, who knows what I’ll be into in a few years. ↩︎
Points nearly directly ripped from VC discussions by aforementioned colleague who provided idea, who will not be named for privacy (yes, I’m looking at all you classmates who I know will stalk anyone I so much as mention in passing on this blog.) reasons. ↩︎
- Yours, Kewbish
< More Posts