Time-Tracker

Natürlich kommt gleich der Einwand: Dafür gibt es massig Lösungen am Markt - wieso selber Arbeit investieren? Berechtigter Punkt.

Die übliche Strukturierung in Projekte, denen man dann Zeiten zuordnen kann, war (und ist) mir zu trivial. Ich möchte Zeiten zu einer “Aufgabe” zuordnen können, die aber ihrerseits eine Unteraufgabe einer anderen Aufgabe ist. Und dies in beliebiger Tiefe. Auch war mir ein Dorn im Auge bei Unterbrechungen einen laufenden Zeiteintrag beenden zu müssen, einen neuen Eintrag für die Unterbrechung zu erstellen und danach dann einen weiteren Eintrag zu der ursprünglichen Aufgabe erstellen zu müssen, der dann die Fortsetzung der unterbrochenen Tätigkeit abbildet. Hier implementiere ich Unter-Events, die dann einfach ihren “Ressourcenverbrauch” von ihren Eltern-Events abziehen. Durch die Zuordnung der einzelnen Events zu individuellen “Tasks” lassen sich auch individuelle Stundensätze und Pausen abbilden. Und weil ich schonmal dabei bin, ist es kein großer Aufwand diese Zeiten jeweils einer Person zuzuordnen. So kann man auch ganze Teams mit dieser Datenstruktur verwalten.

So können später flexibel Auswertungen zu diversen Fragestellungen erstellt werden. Der Datensatz enthält dazu die notwendigen Informationen.

Historie

Die Anfänge dieses Projekts liegen bei mir sehr weit in der Vergangenheit. Die ersten Lösungen habe ich damals mit dBase II erstellt. Später migrierten die Daten dann zu einer Lösung mit einer MS-Access Datenbank auf die ich mit einer .Net Anwendung in C# zugegriffen habe.

Da ich persönlich auf dem Desktop inzwischen von Windows zu Linux gewechselt bin, machte eine .Net Anwendung nicht mehr so viel Spaß. Man kann zwar mit Mono auch auf Linux arbeiten und MS-Access kann man durch SQLite ersetzen, aber es erfordert die Installation dieser Pakete damit die Anwendung lauffähig wird.

Ich hatte meinen Schwerpunkt dann auf die Entwicklung nativer Android-Apps verlegt und so erblickte die Android-Version in Form der Time-Tracker (Android) App das Licht der Welt. Funkionierte für mich persönlich gut, aber für ein Produkt bräuchte es auch Lösungen für die iPhones und die Desktops. Für die Desktops gab es eine Weile lang einen Android-Emlulator in Chrome der für mich erst einmal ausreichte. Aber native iPhone-Apps sind außerhalb meines Interessensbereiches.

Nun habe ich mehr als ein Gerät im Einsatz auf dem ich Daten erfasse. Eine verteilte P2P Datenbank wäre zwar schick, aber ein eigenes Projekt. Also hab ich erstmal auf die naheliegende Lösung zurück gegriffen und ein zentrales Backend gebaut. Dazu konnte ich auf ein weiteres “altes” Projekt von mir zurückgreifen - eine Library die relationale Datenbanken synchronisieren kann. Dies habe ich genutzt anstatt eine dedizierte REST-API zu bauen.

Nun liegt es nahe auch einen Web-Client zu bauen, der ebenfalls auf diese Datenbank zugreift. Umfangreiches Editieren der Daten macht auf Smartphones und Tablets nicht wirklich Spaß. Da ich fit mit PHP bin und ein größeres Projekt mit Symfony gemacht habe, habe ich das Backend dann mit Symfony und um eine klassische Multi-Page Lösung für ein Frontend erweitert. Nichts spektakuläres - Bootstrap, Twig und ein wenig Javascript … Allerdings nicht voll zuende implementiert, denn Multi-Page ist für diesen Anwendungsbereich für mich ein Auslaufmodell. Da wollte ich nicht unnötig Energie investieren.

Die Browser haben sich ja mächtig weiter entwickelt und bieten jetzt Funktionalität, die für viele Anwendungsbereiche eine native Anwendung für Desktop und mobile Geräte unnötig machen. Jetzt kann ich endlich mit vertretbarem Aufwand Anwendungen schreiben, die überall lauffähig sind - solange sie nicht zu sehr an die Innereien des zugrunde liegenden Betriebssystemes müssen. Hier habe ich Vue.js als Grundlage gewählt.

Jetzt macht meine Insellösung mit dem Synchronizer keinen Sinn mehr und eine richtige API muß her. Dafür habe ich mit Symfony und dem API-Project einen geeigneten Kandidaten gefunden, der mir eine Menge an Boilerplate Code abnimmt - meine Freizeit ist ja auch nur begrenzt. ;-) Time-Tracker Backend

Nun wandert der Time-Tracker also zu einer Single-Page-Anwendung. Geplant ist, diese Version auf eine offline-fähige PWA auszubauen mit der Daten auch offline erfasst und später mit dem Backend synchronisiert werden können.

Mal sehen was jetzt aus der Android-Version werden wird. Sieht so aus, als ob ich sie dann mittelfristig nicht mehr brauchen werde.