Title

ClockIn

Author

Jen Spinney

Abstract

A server-side XML driven application to keep track of the number of hours worked for employees or contractors paid by the hour.

What

ClockIn will have the ability to easily log when a user signs in and signs out, regardless of where they are working from. That is, the signing in and signing out processes will be implemented in the form of posting HTTP data to the central server that implements the application logic and data. The raw time data will be kept as an xml flat file on this server. The HTTP posting step will be able to be accomplished by a user in one of two ways: Either the user can use a browser to view the (dynamic, servlet-based) website maintained by the server, or they can download a small java program to implement the client side of ClockIn. Users will be able to "clock in" by either clicking a "clock in" button on the actual website, or simply typing "java clockIn.client.clock in" (or something like that) on any internet-connected machine with the clockIn.client class available. I also may extend the client program to save data itself when there is no available internet connection and post it to the server the next chance it gets.

The website piece of it will be able to be used for things like clocking in or clocking out, but its main purpose will be to provide an interface for creating Excel spreadsheets from the data for use as employee timesheets. Here, the user will be able to control things such as their predictions for next payroll and more.

Why

I'm paid by the hour, and every two weeks I spend about a half hour tediously compiling my timesheet to submit for payroll. A while ago, I automated the signing in and signing out process using a quite and dirty perl script to write some data out to a local file. There are many problems that still exist with this solution. This week, for example, I was sick the day my timesheet was due. I would have been able to submit it from home, except that all of the data was on a computer at work, and remote connections are not allowed into the office subnet. Often, the timesheets are due in the morning. I'm not the earliest of risers, so I would prefer compiling my timesheet from home the night before rather than rushing to meet the deadline in the morning. Hence the need for a centralized server-based repository of the data.

Although the signing in and signing out process has been automated for the past few months, the process of translated all of that data to a nicely-formatted Excel spreadsheet has to be done by hand. It is very tedious and repetitive, and I often wish that I spent my time on more productive endeavors.

Another piece to this is the concept of predictions. Because I have to submit payroll data for the first two weeks of the month several days before the actual first two weeks of the month are up, I have to make time predictions on each timesheet as well as correct for the last timesheet's predictions. Correcting for the last timesheet's predictions is the most ardous part of putting together a timesheet. ClockIn will be able to handle prediction corrections automatically.

How

The webpage interface will all be implemented using Tomcat as an application server using Java servlets. The time data itself will be stored in an XML file. The optional client-side software might be implemented in Java or Perl, and it will use XML to store its data if it doesn't have a working network connection.

For generating the Excel spreadsheets, I hope to be able to output XML directly in a form Excel will understand, if I can get my hands on a copy of Excel 2003 to interpret it correctly (I'm currently using Excel 2000). A more likely scenario is to use XSLT to generate something that Excel will like and be able to format correctly (a csv file in the worst case, if I can't find anything with more formatting options).

Questions

None.