150 likes | 269 Views
Automated Time Tracking From proposal to production. By Chris Gaffney. Hi!. Overview. The Language Resource Center is a lab specifically for language students Students in language courses 202 and below must spend a minimum of 50 minutes per week in the lab
E N D
Automated Time TrackingFrom proposal to production By Chris Gaffney
Overview • The Language Resource Center is a lab specifically for language students • Students in language courses 202 and below must spend a minimum of 50 minutes per week in the lab • Summer 2006: Began planning to switch to an all Mac lab • Need to preserve much of the functionality of our existing system.
Why build our own? • The time tracking of the existing system left much to be desired • There was no preexisting system for OS X that did what we needed • The new system could be tailored for exactly how we used it • The chance to try new technologies
Requirements • Web interface for students, teachers and admins • Operation is completely transparent to most students • Students taking multiple courses would be able to choose which course to track time for • Works with OS X
Development Process • Code is stored in a Subversion repository • I am the only developer • Development is done primarily on Linux for OS X and Windows • Required the use of cross platform languages • Lacked the target environment when development started • Started with prototyping, becoming an expert in the domain
Prototyping • Original concept was that of a web service • http://server/signon/gaffneyc • http://server/signoff/gaffneyc • Extremely thin client (curl, wget, browser) • Web service was not a practical solution • Depended too much on the sign off • Browser was not transparent enough
Prototyping • Second prototype was a dedicated TCP server • Written in Ruby for a quick start, flexibility • TCP allowed for a “tripwire” that alerted the server when the client disconnected, restarted the system, unplugged, etc… • Required a thicker client that implements a very simple protocol
The Server • Written in Ruby to take advantage of the ActiveRecord ORM library and to reuse code from the web interface • Two major designs • Original: 3 threads per connection (timer, saver, and connection thread) • Redesign: No timer thread, single saving thread (serialize writes), 1 thread/connection
Clients • Java Client • This is the actual client that students see • Runs on Windows, Linux, and OS X • Ruby Client • Console client used for testing, prototyping protocol variations, etc… • Objective-C • Coming this summer…?
Web Interface • Deployed midway through the semester • Good response so far from both faculty and students • Preparing to deploy a redesign in the coming week • Original design was hammered out directly in HTML and CSS • Redesign went through a prototype / mocking process before being implemented
Production • System went live on January 8th • One minor hiccup during the first week • Stats (since January) • Sessions: 18298 • Logged Time: 588d 6h 25m 0s • Students: 2156