In the beginning, there was darkness in the world of course registration. A certain coldness loomed over the inevitable scheduling of university courses every summer to make a timetable that works. Then, in 2007, Billy said “let there be automation” and Timetable Builder was born.
Timetable Builder (TTB) is a schedule permutator – supplied with a list of course selections, the system can generate a collection of possible timetables which are maximally compatible with the parameters specified.
In early TTB, there was nothing but the core engine – a command-line Java application which read in a list of user-selected course and section ids from a text file. The engine would make a combination from this list of courses alone.
Billy asked me to try out this new service, and after sending him a list of courses, it gave me back a plausible schedule, and I was thoroughly impressed. I became really curious about how the system works, and after seeing how much detail his team put into handling even the wildest course selections – waitlists, two-termers, and distance-eds.
You’d be a fool to not realize this potential! It was approaching that time of year, just after classes had ended for the winter, when we decided to get the ball rolling. Billy had already formed an initial dev team, with David S. taking care of the engine’s I/O and Tina L. as advertising. I then joined their team, along with Ivy M. and Grace L. for UI design and templates. It wasn’t long (ok, 280 [wo]man-hours) before we had TTB version 1.
It was built using PHP 4 (had to be compatible with the ultra-inexpensive host we had) and was actually hosted on two separate servers – the front-end would connect via HTTP to our back-end server, which was an old desktop running Windows XP, a HTTP server, a MySql server, and several instances of the Timetable Builder engine. It was dubbed the “closet server” as it sat literally in the closet of our residence. It actually heated up the closet quite a bit, and since I only like my clothing so crisp, it ended up sitting under my development desktop.
In this version, we already populated a database with near-mirror copies of current course availablilities on the Student course calendar, and use this data to allow users to simply select which courses they would like to take. There were a couple additional parameters, like a preferred time range and maximizing days off, as well as the ability for your account to save work lists and their corresponding parameters.
As a general workflow, we wanted:
- the front-end would pass worklist requests to the back-end
- the back-end drops them into a queue
- several instances of timetable builder engines (dubbed “busy workers”) periodically check the queue for jobs
- busy workers compile possible timetables and register that in the database
- the front-end detects the timetable has been built and fetches them for displayal