15
Automated Time Tracking From proposal to production By Chris Gaffney

Automated Time Tracking From proposal to production

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

Automated Time TrackingFrom 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

• 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

Original Design

New Design

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