1 / 15

Automated Time Tracking From proposal to production

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

quentin-good
Télécharger la présentation

Automated Time Tracking From proposal to production

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automated Time TrackingFrom proposal to production By Chris Gaffney

  2. Hi!

  3. 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.

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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…?

  11. 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

  12. Original Design

  13. New Design

  14. 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

More Related