Publishing the v2.0 of my Excel timesheet

The origins

Why, oh why?

I am a consultant developer. This means I move from client to client and share their time constraints. This includes deadlines, but also work time.

It so happens that some clients have a time clock, like in the old days.

Time clock in the Museum at Wookey Hole Caves (Source: Wikimedia)
Some have these time clocks…
Electronic clocking terminal (Source: Wikimedia, February 2009)
… but this is more likely.

My problem is: while most of my client’s employees can see what the clock stores, I, as an extern, cannot. I do not like to be blind, so each time I am in this situation, like many people I know, I make an Excel sheet where I log my check-ins and -outs.

Sharing my timesheet…

On my latest mission, we were several on the team from the same company. I spent some days without my usual timesheet and when I grew tired, I sent my first basic version, with some conditional formatting, to all members there.

Since they did not seem very interested if I asked whether something standard was available, I did not expect much. But instead, I quickly got some feedback: they asked new features, signalled some bugs, …

The team grew, the requests followed. The possibilities of the timesheet were ever greater, and therefore so was its complexity.

… with the whole world

Finally, using e-mails to track the feedback and release the changelog and user manual became too heavy. I thought of a bug tracker. This led me to create a Github repository. The wiki would come in handy for the user manual too.

Thus the work on version 2, which should make the sheet less specific to our context and more widely usable, began.

And now version 2.0 is here!.

The construct

Choosing the format for storing revisions of the timesheet

The choice of using Excel for the timesheet comes with a consequence: the file we edit is a binary. We know one thing about GIT (and most RCSs) is that it is not that efficient with binaries.

But we also know that a .xlsx file is just a zip of XML files, so we chose to save it as the exploded version of the .zip file.

The only thing we lacked was a way to easily switch to and fro between both forms.

Searching for the tool

I ambitioned at having one script that could be used with an argument to do this. It is easy in Unix. I even found a solution using PowerShell for Windows. But this required to maintain two scripts.

I looked at the build tools I know and some I did not: Maven, Gradle, CMake, …

But all these are oriented towards a specific technology and all of them require to install something on your computer.

Making the tool…

I am a developer after all, and this is within my area. So I went for an executable .jar. Only thing you need to have on your computer? An up-to-date version of Java.

And I came up with a basic Swing interface.

The construct
The construct

It may not look like much, but it does the job…

… and enhancing it

… and it will do more.

Do not hesitate to head over to the repository and fork it to tailor it to your own needs or make this one better.

In the end, it will make developing the xls-time-tracker timesheet and managing its versions easier.

Just wait and see…

The Cost of Time

This morning, I arrived at work, booted my machine and launched the core applications I need before even thinking of starting to work: Outlook, so that I can read the e-mail I might have received, Chrome, to see what is new in JIRA, and of course Eclipse which will be used for all development.

Can you guess how long it took to boot and launch only those three? 10 or 15 minutes. Not so much. Just a quarter of an hour lost before even beginning working.

And even once all this was finally up (Eclipse easily took three full minutes), just reading and answering e-mail was a pain. Opening a new tab in Chrome made me wait twenty seconds before I could begin typing in the omnibar, my input for a new message in Outlook had a delay of several seconds, …

It is my (maybe not-so-humble, sorry) opinion that when a developer is faster than his/her machine, there is a problem.

At home, booting1 takes two minutes (half of it being after Windows started). That is already undoubtedly faster than what I have at work, but applications launch in a few seconds too, and they never lag once they are up. Admittedly, I have a killer machine (there was a reason for buying it, even if it is gone now).

But that gives some thinking: lost time is lost money for a company. Which is the most advantageous between losing developer time or buying a efficient machine?

Continue reading The Cost of Time