Damit alles einheitlich ist und die Wahrscheinlichkeit für rückfragen minimiert wird (Issues) und alles was geändert wurde beschrieben wird (pull requests).

Description

Ich habe die Funktion für ein automatisches Tracken der Zeit hinzugefügt

Related Issue

Issue #37

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

Description

Ich überprüfe mit einer Regex ob das eingegebene Datum auch 1. ein Datum ist und 2. das gültige Format besitzt. Mit einer anderen Regex wird überprüft, ob auch nur Zahlen als Argument bei --add übergeben werden. Bei falscher Eingabe wird dies "Ungültige Eingabe" in die Konsole geschrieben und der ERROR Status zurückgegeben, sodass kein Event mit falschen Daten erstellt wird.

Related Issue

Wie beschrieben in #35 .

Screenshots (if appropriate):

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

Describe the bug Man kann bei --add jeden String als Datum wählen und er wird so im Event abgespeichert. Außerdem wird ein nicht-Zahlen String als Argument nicht abgefangen.

To Reproduce Steps to reproduce the behavior: java -jar tt.jar --add hallo,90,Test,"Test" für das Datum java -jar tt.jar --add today,drei,Test,"Test" für das Argument

Expected behavior Ich habe eigentlich erwartet, dass bei ungültigem Datum (und ungültigem Datumsformat) und bei einem String, der keine gültige Zahl ist, ein ERROR Status zurückgegeben wird.

Screenshots Dieser Screenshot zeigt die Ausgabe der Tabelle mit ungültigen Daten.

Wo wir ja jetzt eine tabellarische Anzeige eingefügt haben, sollten wir das dann nicht auch in der ReadMe reinschreiben, dass das jetzt möglich ist? Und in die readme noch reinschreiben, dass es einen "-help" Befehl gibt, so der Vollständigkeit halber?

Vielleicht wäre ja ein Befehl --track-start , der sich durch einen Befehl --track-done abschließen lässt und dann automatisch einen Eintrag hinzufügt, mit dem Datum des Beginns und den Minuten, die zwischen start und done vergangen sind, ganz cool.

Bei Bedarf noch ein --track-pause und --track-unpause, womit man das Tracken auch pausieren kann. Aber das ist eher weniger wichtig denke ich :D

Das sähe dann in etwa so aus:

[2022-06-10 10:00] java -jar tt.jar --track-start Propra1 [2022-06-10 10:40] java -jar tt.jar --track-done "Neues Issue für time-tracker erstellt"

Diese Befehle sollten dann ein neues Event speichern, so als ob man diesen Befehl eingegeben hätte:

java -jar tt.jar --add 2022-06-10,40,Propra1,"Neues Issue für time-tracker erstellt"

We can filter by project in the Sum function as well as in the Table function, wouldn't it be interesting to filter by date to see what was done on a certain day?

Description

This PR add 4 badges (Provided by Shields.io) at the top of the README to display the following information:

• Workflow Status (Did the gradle checks pass or fail?)
• No. of Issues
• Commit activity per week
• License

These badges allow an easy overview of the project status. They help to see if the project is actively maintained and whether it's working in it's current state.

Related Issue

N/A

Screenshots:

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

Description

Added the new functions in the README.md

Related Issue

Relatet to issue #21

Motivation and Context

Updated the README.md

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [x] All new and existing tests passed.

Man kann nun --add today benutzen, um ein Event am 25.05.2022 hinzuzufügen, anstatt --add 2022-05-25 schreiben zu müssen. Beinhaltet auch eine Build Configuration zum Ausprobieren.

Vorheriger Pull Request hatte Konflikte wegen des zuvor akzeptierten PRs :D

Außerdem hab ich die Tests umbenannt, weil die Reihenfolge bei der Benennung nicht ganz gepasst hat

https://github.com/hhu-propra1/time-tracker/blob/main/src/main/java/de/propra/timetracker/TablePrinter.java#L9-L11

Diese drei Zeilen und die Zeilen da drunter sind die selben. Also bitte einmal extrahieren und nur einmal definieren :-)

"old" GitHub had a punchcard diagram to show you the most active hours of the day.

This is great to gain insight about one's daily productivity rhythm.