It took a while but now we finally released version 0.7.0 containing the Gradle plugin for OpenFastTrace 3.0.2.

There where some issues that delayed the release:

• The configuration of plugins changed in Gradle 6.0. The old API is deprecated and will be removed in Gradle 7.0, so we had to migrate to the new API.
• Calculating the test coverage of Gradle plugin integration tests requires plugin jacoco-gradle-testkit-plugin. With new Gradle versions the test task fails under Windows with exception message Failed to create MD5 hash for file content. This is a known issue caused by a gradle background process locking the Jacoco coverage result file build/jacoco/test.exec. Fortunately there is a workaround described in the issue. Now Sonarcloud reports a test coverage of 90% for the plugin.

The new Gradle plugin requires Java 11 and Gradle 6.0. We ensure compatibility with versions 6.0 and 6.4.1 with additional integration tests.

The previous blog post was published more than one year ago. That’s why it’s high time for an update. We where busy in the last weeks preparing some new releases for you!

OpenFastTrace 3.0.2

This major release contains these changes:

• The project now requires Java 11 for building and running.
• We re-structured the packages to have unique package names for each sub-module. This is a precondition for Java 9 modules which we will introduce later.
• The tag importer now supports many more file types, e.g. for C, C++, SQL and many more.

OpenFastTrace Maven Plugin 0.1.0

This is the first release we recommend for production use as we added integration tests for real use cases. We upgraded to the latest OFT release and introduced a feature to optionally fail the build when tracing finds an error.

We are happy to announce the latest release 2.3.5 of OpenFastTrace.

In this release we split the source code into sub-modules for api, importers, exporters etc. This has some advantages:

• The dependencies of plugins are now enforced by the compiler. It is not possible that e.g. the specobject exporter depends on the specobject importer.
• Developers who want to extend OFT with custom importers or exporters only need add a dependency for the stable API module without all the other internal code.
• A stable API simplifies internal refactoring of the code because third party plugins only depend on the API module. All other modules are internal and can be changed without breaking third party plugins.

I also should mention some caveats. Building the project now takes around 3 minutes, deployment to JCenter even 9 minutes.

Currently the API module contains some plugin specific classes for configuration. We plan to clean this up in one of the next releases.

To make it easier for users and third party developers we also maintain a changelog with all the important changes in each release. The changelog follows the structure of Keep a changelog.

Of course we also released version 0.6.2 of the gradle plugin which uses the new OpenFastTrace 2.3.5. The gradle plugin now also contains a changelog.

Please upgrade to the new versions and share your experience.

Happy Tracing!

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

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!

Today we released version 0.6.0 of the Gradle plugin which includes OpenFastTrace 2.2.0 and supports HTML reports.

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!