read more
Hi UNC Class Checker Staff,
I was curious as to what language you guys used (backend) to create
the website and the biggest hurdles you went through with getting it
right. Also was wondering if you guys have it open sourced as well.
Thanks.
Hi Kousha,
Very sorry about the terribly late response; we don't check this email very often anymore.
Boy, is it a story. In the summer before my freshman year at UNC, I (Joe) wrote the first, very basic, version of Class Checker in a language called AppleScript. This first version actually just sent me screenshots of my shopping cart every 10 minutes so that I could manually check to see if a class had opened. After a friend suggested we make it public, I packaged it up as a Mac App and modified it so that it would only text or email a user once a class in their shopping cart had actually changed status. I spent a lot of time trying to figure out how I could rewrite it with Java and curl before making the Mac App, but my knowledge of curl at the time was no match for UNC's authentication system. So, we tried to distribute the Mac App and hit our first huge block: nobody wanted to download a stupid Mac App, even when they understood the potential benefits. We sent it out to ~70 of our friends in the first few weeks of our freshman year and I think only 5-7 actually were interested enough to email us about it. This was pretty discouraging, and in a lot of ways I abandoned the goal of trying to push it out to other students.
I continued to use it on my own, though, and a few of our friends still used it. When the next registration period came, a friend texted us and asked if I could track classes for him, then let him know anytime I got notified. This tiny request made me realize (it seems ridiculous now that I didn't think of this earlier) that I could restructure Class Checker so that, instead of everyone having to download an application and run it themselves, they would simply send me what classes they wanted tracked, I would add them to my shopping cart, and then my AppleScript program would email or text all interested users when a class changed status. That centralized model made a huge difference: our first semester we had 5 users, our second we had 900.
Because I didn't really have any idea of how to structure something like this, the entirety of Class Checker at the beginning was just a bag of ridiculous hacks. We setup our (old) website (https://uncchecker.wordpress.com/), where users could submit a form with the classes they wanted tracked. These forms would go to an email setup on my Hackintosh, which (when new mail was detected) would run an AppleScript that would parse the information and add it to a database, as well as trigger another script which would programmatically add any previously untracked classes to my shopping cart, all while yet another AppleScript was running in the background that refreshed my shopping cart page to see if there were any class changes and notify users. Because of the reliance on mail rules in this setup, if any two users submitted a form within the same minute, the second user's classes wouldn't get tracked. This was a huge headache because it meant that we had to manually go through every submission to make sure the user actually made it into our database. Also, only at the end of our first successful registration period did I discover (based on feedback from a user), that some SQL statement inefficiencies on my part had resulted in users getting their notifications between 2 and 20 minutes late. The fix was easy, but it was hard to swallow that mistake.
As we grew, we started sending a really ridiculous amount of email (we send texts via email, which is why we need to know your carrier). At peak periods, we'd send 10,000 emails in a day, which means we started hitting mail limits on our Gmail accounts. This was another problem: how do we send huge amounts of email for free (we weren't charging students and we didn't want to start, so we wanted our operating costs to be pretty much zero). Our solution was to sign up for 30+ Gmail accounts, and distribute the emails we sent out among these 30 accounts. That way, we didn't have a single point of failure.
Today, we're a team of three and all of the AppleScript has been replaced with Python (so it is our Python scripts which actually notify users of class changes, so you can consider that our backend). I made our website validate user input with regex which alleviated yet another huge headache, and PHP ties the website's forms to the Python. Huge changes, but we still use the same mailing method to keep our expenses near-zero. Our code isn't open source right now, not sure yet if that'll change.
Please CC my personal email (joe@pooch.us) if you respond, so that your email doesn't get forgotten in this inbox again.
Thanks,
Joe