Initially, when I finished writing the script for the automated registration, I didn’t want to open-source it right away because I had plans to monetize it. I also realized that I couldn’t keep this bot just for myself because apparently a lot of people had trouble signing up for full classes. Students would get a text/email notification saying that there’s an open space for a class that they put on their watchlist and then they would have to manually add it by going to the registration page. And many experienced the frustration of not getting to the registration page on time and so they’d be out of luck.

So at the end of my summer, I figured I should start working on a web interface so people can start using my service using their existing Penn State email. I’ve decided to go with an auction-based service. The first-come first-serve basis doesn’t really resonate with me. If in a case where I really needed a particular class in order to graduate next semester, I would be more likely to pay than to snipe my registration page.

So once they’ve signed up and logged in they’re able to bid on classes that they want. Minimum bids are listed in the home page.

The homepage.

So this is the homepage where the students can signup with their existing Penn State email. After a user submits the form for signing up, the backend then checks whether its a valid Penn State by logging in to the Penn State portal.

Page for adding a class




Students from all branch campuses can use this app. Once they choose the right campus and appropriate class, the backend spawns a daemon that does all the automated registration. The backend also validates the class entered by the student by POSTing to an endpoint on Penn States web servers that checks for seat availability.

View for adding exceptions

The student also has the option to specify class sections that they may want to include or exclude in the script from adding to the students schedule.

So for instance a student may exclude a class section that they may have a scheduling conflict with. In the case that they have a scheduling conflict and they don’t add any exceptions, the backend will receive an error response from the daemon and will then pause the bid and notify the student by email or phone that there has been a conflict and that they should resolve it by including or excluding the appropriate sections.

Current bids for logged in user

This is the bids page where students can pause or remove any bids they have placed for classes.

TODO


There is an endpoint on Penn States web servers that allows you to query seat availability for courses. My script posts to that endpoint every few seconds or so and it’d be likely that someone would detect such an activity. So to work a way around this, I thought of having Penn States notification system send a text to a Twillio number instead of my personal number. That way I can set up a callback url to receive the text from Penn State and parse it to get the course and course level instead of having to overload Penn States webservers by posting to it every few seconds. The backend, having received the course prefix and number (from parsing the Twillio text), can then query the database for the course record and retrieve the highest bidder.