Time recording tool

To keep track of my working time I wrote a small time recording tool called White Rabbit. You can find it at https://github.com/itsallcode/white-rabbit.

Features

  • Simple text user interface
  • Records begin, end and interruption of your working day
  • Data storage in human readable json files, one file per month
  • Manual interruptions: press i to start and stop interruptions
  • Supports weekend, public holiday, vacation, flex time and sickness (see json example)
  • Reporting of total overtime: press r
  • Automatic update in the background (press u to update manually): just keep it running and it will record your working time
    • Start of work is detected via
      • Program start
      • Computer resumes from sleep in the morning
    • End of work is detected via
      • Program shutdown
      • Computer sleeps for the rest of the day
  • Interruptions added when computer sleeps for more than 2 minutes
  • Assumptions:
    • Working time of 8h Monday to Friday
    • Mandatory break of 45 minutes after 6 hours of working

Architectural descisions

The architecture separates business logic (sub-project logic) from the user interface (textui). This allows you to add additional user interfaces e.g. using JavaFX or Swing.

We use JSON for storage because this enables the user to manually make changes (e.g. add a sick day).  So we can keep the user interface as simple as possible.

Example data file

{
    "year": 2019,
    "month": "MARCH",
    "days": [
        {
            "date": "2019-03-01",
            "begin": "08:00:00",
            "end": "17:00:00",
            "comment": "First working day (type WORK is optional)"
        },
        {
            "date": "2019-03-04",
            "type": "VACATION",
            "comment": "Vacation day, no change to working time"
        },
        {
            "date": "2019-03-05",
            "type": "FLEX_TIME",
            "comment": "Flex time, deducts 8h from your time"
        },
        {
            "date": "2019-03-06",
            "type": "HOLIDAY",
            "comment": "A public holiday, not working"
        },
        {
            "date": "2019-03-07",
            "type": "SICK",
            "comment": "Sick day, no change to working time"
        },
        {
            "date": "2019-03-08",
            "begin": "08:00:00",
            "end": "18:30:00",
            "interruption": "PT1H20M",
            "comment": "1h 20min of interruption"
        },
        {
            "date": "2019-03-09",
            "type": "WEEKEND",
            "comment": "Saturday and Sunday automatically detected, no need to add them here."
        }
    ]
}

Example report

2019-03-01 Fri WORK      08:00 - 17:00 break: 00:45, working time: 08:15, overtime: 00:15, Acc. overtime: 00:15, First working day (type WORK is optional)
2019-03-04 Mon VACATION                break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: 00:15, Vacation day, no change to working time
2019-03-05 Tue FLEX_TIME               break: 00:00, working time: 00:00, overtime: -08:00, Acc. overtime: -07:45, Flex time, deducts 8h from your time
2019-03-06 Wed HOLIDAY                 break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: -07:45, A public holiday, not working
2019-03-07 Thu SICK                    break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: -07:45, Sick day, no change to working time
2019-03-08 Fri WORK      08:00 - 18:30 break: 00:45, interr.: 01:20, working time: 08:25, overtime: 00:25, Acc. overtime: -07:20, 1h 20min of interruption
2019-03-09 Sat WEEKEND                 break: 00:00, working time: 00:00, overtime: 00:00, Acc. overtime: -07:20, Saturday and Sunday automatically detected, no need to add them here.
Total overtime: PT-7H-20M

Maven plugin for OFT created

Today we started a new project for creating a Maven plugin for OpenFastTrace. This will allow you to trace requirements not only with the command line and Gradle but also with Maven!

The project is still in its early stage but you can already trace requirements with the default configuration and a first integration test is working. See Pull Request #1 for the current sources. Reviews are welcome!

 

 

Recovering JPGS from a broken file system on a flash disk

Today I want to thank the author of recoverjpg, Samuel Tardieu. This tool is proof that “do one thing, do it well” results in the most useful software.

A family member brought an SD card back from a vacation trip abroad and the filesystem broke when she plugged the card into her Mac. Needless to say that this is not the usual scenario, because many times before everything went well.

Having (partially) restored broken filesystems or at least files, I knew the drill. First rule: don’t attempt to restore on the volume that failed directly. So I created a 1:1 copy of the broken filesystem with the dd command that comes with any Linux installation.

Attempts to restore the filesystem itself failed. The structure was so broken, that fsck.vfat did not succeed. At that point I already pictured myself trying to repair parts with a hex editor. But then I found recoverjpg and it looks for typical structures that look like a JPG file without caring about the filesystem itself too much. That did the trick.

Thanks Samuel!

Gradle plugin upgraded to OpenFastTrace 2.1.0

After releasing OpenFastTrace 2.1.0 it was high time to release the corresponding Gradle plugin in version 0.5.0. This is a drop-in update, just update the version number and benefit from the features and bugfixes of OFT 2.1.0.

During the release process we also fixed the sonar analysis and some sonar warnings.

We also used the opportunity to document (and test) two features that where already implemented but not described:

OpenFastTrace 2.1.0 released

After two bugfix releases a new feature release. On November 19th Christoph create the Release for OpenFastTrace 2.1.0.

Feature-wise we are happy to announce an improved HTML report.

Sonar checks are now up and running again and the last JavaDoc errors have been rooted out.

We also fixed the deep coverage detection which was pointing upwards instead of downwards in the tracing chain. As a consequence we had to rework link loop detection, which acts a lot smarter now than before.

Enjoy this release, which is a huge step forward for OFT!

On refactoring an hidden technical dept

Can you accumulate technical dept, even if you regularly clean up your sources meticulously? A short while ago I would have said that this is possible but unlikely. That was before I started taking on the migration of all of OpenFastTrace‘s unit tests from JUnit4 to JUnit5.

Like most non-trivial projects OFT accumulated quite a number of unit tests over the years and although it was always the plan to move to JUnit5 some day, they were all written for JUnit4.  With the arrival of OFT 2.0.0 — which also was a major refactoring endeavor — I felt now would be the perfect time to make that migration happen. After all I was in the refactoring flow.

To rule them all…

Shouldn’t take long, right? Boy was I mistaken. The one thing I completely underestimated was how dependent many of our integration tests were on JUnit rules like Stefan Birkner’s “JUnit System Rules“. While getting the dependencies right in the Maven POM was only slightly harder than anticipated, migrating all parts where rules were used took way longer. I quickly found a replacement for the “Temporary Folder API“: JUnit Pioneer’s “TempDirectory Extension“.

Homebrew extensions

I did not find a suitable replacement of the JUnit System Rules though, so I decided to take matters into my own hands and create the “JUnit5 System Extensions“. At the time of this writing they cover System.out, System.err and System.exit assertions.

It was a good if also painful practice for writing JUnit5 extensions. Only later I realized that Stefan seems to have started a port of his rules, but it did not look finished to me. Anyway this gave me the opportunity to dive deeper into the JUnit 5 life cycle.

Run baby, run baby, run baby, run!

Christoph was the one who pointed out to me, that the tests I wrote only ran in Eclipse but were silently skipped when triggered by Maven. The culprit was an older version of the Surefire plugin for Maven. Turns out that you need 2.22.1.

Simply beautiful

Even though the migration turned out to be much more of a pain than anticipated, especially integration tests and test that check for exceptions looks much nicer thanks to JUnit5. It’s about time for this upgrade and I am sure we won’t regret this when writing new tests.