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.

TTB Engine has creating you worklists to see in notepad!

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.

Well, it was mostly functional. The dashboard menu on the left is actually just a big picture.

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.

It's the one on the bottom.

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:

1. the front-end would pass worklist requests to the back-end
2. the back-end drops them into a queue
3. several instances of timetable builder engines (dubbed “busy workers”) periodically check the queue for jobs
4. busy workers compile possible timetables and register that in the database
5. the front-end detects the timetable has been built and fetches them for displayal

This works well in theory. Problems arose: this wasn’t the fastest computer on the block – in fact, it was only 1.6 Ghz with 512 MB of RAM, so one instance of busy worker running by itself could still take several minutes to complete one user’s request. There was some network lag between the front-end and the back-end, which didn’t help either. We encountered compatability problems with this version, leaving the application inoperable for certain users – and we have yet to resolve why. However, we were able to gather lots of valuable data – what users liked, disliked, and requested – and we still firmly believed TTB could be successful. Unfortunately, the second semester of school quickly knocked all the developers into hiatus.

However, during my co-op work term of 2008 I managed to gather much information on structured web application development. Armed with the knowledge and design structure patterns we gained from version 1, I put together a prototype for version 2 – should it be deployed, the new system utilizes Java 2 Enterprise Edition and assisting technologies such as Spring, Hibernate ORM and AOP to allow us to build a modular, optimized application.

Alpha version of TTB 2

From the front-end, of course, the user can’t really see what’s going on, but in the back-end it makes all the difference. Some advantages of using Java as an interpreter is so we can call the TTB engine on demand, create low coupled, highly cohesive packages, and never have to write a line of SQL or scrub form inputs (via the usage of the technologies mentioned earlier). It will also be much easier to ramp up a new developer, should we need to. Much of the design flow and front-end design has already been successfully ported to version 2.

As of this post, development on Timetable Builder v. 2 is still on hold due to time restraints, and the front-end of v. 1 sits crippled on our web host (the back-end server is unplugged somewhere in Billy’s house). In the near future we hope we can present you version 2. Stay tuned for a tutorial on how to start developing J2EE applications!