pindrop
/
timetracker
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated documentation, especially mentioning Rust programs

This commit is contained in:
Trey Blancher 2022-12-20 13:21:20 -05:00
parent 914a57692f
commit ec4e21878a
2 changed files with 188 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
INSTALL.md
View File

@ -1,6 +1,28 @@
# timetracker INSTALL
## Basic Installation
Use `git clone` to create a local copy of the timetracker repository on your local MacBook Pro. If you'd rather use the older, slower Python/Bash scripts, you can then copy or link the `timetracker.py`, `do_process.sh`, and `chug.sh` files into your path. I like to keep these in a `~/timetracker` directory, where I execute them with a leading `./` so they don't need to be in my `PATH` variable.
There are some things that you need to do in order to use timetracker like a pro. Here are the basics:
If you'd prefer to use the Rust programs (which is highly recommended, if only for execution speed), you will need to compile the Rust programs with `cargo` (the Rust language package manager). Do the following:
1. Install the `rust` package from Homebrew:
```
brew install rust
```
Homebrew may update itself before installing `rust`.
1. Navigate to the `timetracker/rust/timetracking` directory in the cloned `timetracker` source directory
1. Execute the following command:
```
cargo build --release
```
If you are intending to debug or otherwise develop the Rust programs, I recommend creating a fork on GitHub, making your proposed changes in your local clone of the fork, and then issue a PR against my parent repository. In that case you can drop the `--release` argument, which will keep debugging symbols and such in the executable.
1. The compiled executables will be in the `target/release` or the `target/debug` subdirectories, depending on whether you provided `--release` to the build step (without this flag the executables will be in the `debug` subdirectory). You may copy them or link them to your `PATH` (e.g., `~/bin`) for use.
- Note that if you're working on a specific program in the package, you can change directory to whichever executable you're working on (`chug`, `doprocess`, `timetracker`, or the library package `timelogging`), you will likely want to run the debug version directly, like so:
```
cargo run -- <input arguments>
```
## Pro Tips
There are some things that you need to do in order to use timetracker like a pro. These instructions assume you're using the vim or gvim (GUI) editor. There are likely similar macros you can enable for editors such as Atom or Sublime, but you'll have to review the documentation for those editors to be able to reproduce the ideas there.
Here are the basics:
1. Install Keyboard Maestro from the MSC. If it is not available to you, send a helpdesk request to helpdesk@pindrop.com to request it. Install it using the standard MSC method.
1. Launch Keyboard Maestro. Two pieces should launch, the Editor and the Engine. If the Engine is loaded you should see the ![Keyboard Maestro icon][KM_icon] in your toolbar.
@ -8,21 +30,19 @@ There are some things that you need to do in order to use timetracker like a pro
1. Enable the "Insert Timestamp Begin" and "Insert Timestamp End" macros: ![Begin/End][enable_macros]. To select multiple macros hold down the "Command" ('⌘') and click each desired macro. Then click "Enable or Disable Macro" at the bottom of the Keyboard Maestro Editor window, in the center pane under "Macros".
* If desired, you can modify the trigger for these macros at this time: ![Change Trigger][change_trigger]. You'll have to do this for each macro individually.
* As imported, the Begin and End macros are triggered by: ⌘+Shift+D
5. You can repeat the above process for the "Insert Date (ISO 8601 format)" macro, which will allow you to quickly type out today's date in ISO-8601 date standard formate (e.g., "2020-04-07").
1. You can repeat the above process for the "Insert Date (ISO 8601 format)" macro, which will allow you to quickly type out today's date in ISO-8601 date standard formate (e.g., "2020-04-07").
1. Now that you have the basic Begin and End macros imported and enabled, you can begin using them. In your favorite terminal emulator (e.g. iTerm2 or Terminal.app), open vim on today's log file:
```
cd ~/timetracker
vim 2020-04-07.log
```
Or, if you prefer, use gvim or Mac vim GUI programs.
7. If you haven't already, copy the .vimrc file from the timetracker GitHub repository to your home directory (`/Users/<username>/`, or `~/`). If you already have a .vimrc file that has your own customizations in it, consider adding the following line to your .vimrc:
1. If you haven't already, copy the .vimrc file from the timetracker GitHub repository to your home directory (`/Users/<username>/`, or `~/`). If you already have a .vimrc file that has your own customizations in it, consider adding the following line to your .vimrc:
```
nmap Y y$
```
If you do not do this you will have to modify the vim macro (see below).
8. The Keyboard Maestro macros make use of the `@a` vim macro. To record it in vim:
1. The Keyboard Maestro macros make use of the `@a` vim macro. To record it in vim:
* Press `q`, then release, and then type `a`. You should now see `recording @a` in the vim status line at the bottom of your vim window.
* Press Escape (`Esc`) to go into normal/command vim mode (where you can navigate with `hjkl` keys).
* If you are using the timetracker .vimrc, or have made the suggested edit to your own .vimrc, type the following keys:
@ -36,9 +56,9 @@ There are some things that you need to do in order to use timetracker like a pro
* Press `q` again to stop recording the macro.
* Trigger the vim macro by typing `@a` (the "Insert Timestamp End" macro does this automatically)
What these vim macros do is copy the category and task name from the above line (should be a Begin task), and paste it to the end of the End line. This should eliminate any mistakes when setting the end time of a task. Note that if a mistake is made on the Begin line, that mistake will be propagated to the End line when the "Insert Timestampt End" macro is executed.
9. Both the "Insert Timestamp Begin" and "Insert Timestamp End" macros automatically press the Escape key (`Esc`), so you can trigger them from normal/command mode, or insert mode. In vim, trigger the "Insert Timestamp Begin" macro by typing `⌘+Shift+D`, then `B` (or whatever you changed the trigger to be). If you haven't changed the trigger, a ![Conflict Dialog][conflict_dialog] will pop up, where you can choose the desired macro (either with your mouse, or by typing `B` for Begin, or `E` for End).
1. Both the "Insert Timestamp Begin" and "Insert Timestamp End" macros automatically press the Escape key (`Esc`), so you can trigger them from normal/command mode, or insert mode. In vim, trigger the "Insert Timestamp Begin" macro by typing `⌘+Shift+D`, then `B` (or whatever you changed the trigger to be). If you haven't changed the trigger, a ![Conflict Dialog][conflict_dialog] will pop up, where you can choose the desired macro (either with your mouse, or by typing `B` for Begin, or `E` for End).
1. If you have chosen the "Insert Timestamp Begin" macro, you can type a category (`[In Square Brackets]`), then the title of the task you are beginning. Note that the title is free form, but having square brackets in the title, outside of the category is untested. Any other characters should be valid.
- NOTE: If you use the Rust programs for digesting your logs, having multiple categories/strings inside square brackets will case the Rust program to panic. The older Python/Bash scripts handle this a bit more gracefully at the time of this writing.
1. When you're finished with the task, run the "Insert Timestamp End" macro. You should see the timestamp with the "End" keyword, and the category and title of the above Begin task copied verbatim. Then the macro will automatically print another Begin line, ready for the next task.
Reach out to me (Trey Blancher, tblancher@pindrop.com), if you have questions or problems with this procedure. Or better yet, file an issue under the timetracker repository on GitHub.

213
README.md
View File

@ -9,34 +9,141 @@ This framework is what I use to keep track of my time, as I work. Only one task
## log file format
```
2017-12-08 08:21:27: Begin [Productive Non-billable] email triage
2017-12-08 08:59:05: End [Productive Non-billable] email triage
2017-12-08 08:59:06: Begin [CS Support] internal task 1
2017-12-08 09:10:55: End [CS Support] internal task 1
2017-12-08 09:10:56: Begin [Productive Non-billable] internal task 1
2017-12-08 09:15:14: End [Productive Non-billable] internal task 1
2017-12-08 09:15:14: Begin [Customer 1] task 1
2017-12-08 09:19:52: End [Customer 1] task 1
2017-12-08 09:19:52: Begin [Customer 1] PDROP-0000000 case-related task 1
2017-12-08 09:27:37: End [Customer 1] PDROP-0000000 case-related task 1
2017-12-08 09:27:38: Begin [Customer 2] task 2
2017-12-08 11:00:39: End [Customer 2] task 2
2017-12-08 11:00:40: Begin [Customer 1] PDROP-0000000 case-related task 2
2017-12-08 11:07:24: End [Customer 1] PDROP-0000000 case-related task 2
2017-12-08 11:08:56: Begin [CS Support] internal task 2
2017-12-08 11:25:43: End [CS Support] internal task 2
2017-12-08 12:47:50: Begin [Customer 1] PDROP-0000000 case-related task 1
2017-12-08 13:31:52: End [Customer 1] PDROP-0000000 case-related task 1
2017-12-08 13:31:52: Begin [Customer 3] external meeting
2017-12-08 14:11:13: End [Customer 3] external meeting
2017-12-09 14:11:14: Begin [CS Support] documentation creation
2017-12-09 17:01:47: End [CS Support] documentation creation
2017-12-08 08:21:27: Begin [Internal] email triage
2017-12-08 08:59:05: End [Internal] email triage
2017-12-08 08:59:06: Begin [Internal] internal task 1
2017-12-08 09:10:55: End [Internal] internal task 1
2017-12-08 09:10:56: Begin [Internal] internal task 1
2017-12-08 09:15:14: End [Internal] internal task 1
2017-12-08 09:15:14: Begin [Cloud] Customer 1 task 1
2017-12-08 09:19:52: End [Cloud] Customer 1 task 1
2017-12-08 09:19:52: Begin [Cloud] Customer 1 PDROP-0000000 case-related task 1
2017-12-08 09:27:37: End [Cloud] Customer 1 PDROP-0000000 case-related task 1
2017-12-08 09:27:38: Begin [Cloud] Customer 2 task 2
2017-12-08 11:00:39: End [Cloud] Customer 2 task 2
2017-12-08 11:00:40: Begin [On Prem] Customer 1 PDROP-0000000 case-related task 2
2017-12-08 11:07:24: End [On Prem] Customer 1 PDROP-0000000 case-related task 2
2017-12-08 11:08:56: Begin [Internal] internal task 2
2017-12-08 11:25:43: End [Internal] internal task 2
2017-12-08 12:47:50: Begin [Cloud] Customer 1 PDROP-0000000 case-related task 1
2017-12-08 13:31:52: End [Cloud] Customer 1 PDROP-0000000 case-related task 1
2017-12-08 13:31:52: Begin [On Prem] Customer 3 external meeting
2017-12-08 14:11:13: End [On Prem] Customer 3 external meeting
2017-12-09 14:11:14: Begin [Internal] documentation creation
2017-12-09 17:01:47: End [Internal] documentation creation
```
The timestamp is in most-to-least significant units, though any valid date and time should work (however, any other format is untested. BEWARE!). The separator between the timestamp and the Begin or End keywoards is `: `, literally a colon followed by **two** spaces. Anything else will break timetracker.py, and the rest of it will fall down. Each task must have a `Begin` and `End` line, or else the output of timetracker will not be correct. Too many begins or ends should be detected by timetracker.py. The name of the task is free form, and must be identical for the Begin and End (otherwise timetracker.py will think they're different tasks).
The timestamp is naive, it is assumed to be in your local timezone. It is also in most-to-least significant units, though any valid date and naive time should work (however, any other format is untested. BEWARE!, also, the Rust programs will not work with any other format). The separator between the timestamp and the Begin or End keywoards is `: `, literally a colon followed by **two** spaces. Anything else will break timetracker.py (and the Rust version), and the rest of it will fall down. Each task must have a `Begin` and `End` line, or else the output of timetracker will not be correct. Too many begins or ends should be detected by timetracker.py, but this will likely cause a panic in the Rust programs. The name of the task is free form, and must be identical for the Begin and End (otherwise timetracker.py will think they're different tasks).
Certain strings have special meaning to timetracker.py. The category name in square brackets specifies that the task is related to a specific customer, or should be tracked on a certain item in Clarizen, to make transferring to Clarizen more straightforward. These can be any string, even with spaces, but beware of using shell special characters. The names can be anything, so things like `[BB&T]`, `[Citi]`, `[Wells Fargo]`, or `[CS Support]` are perfectly valid. For the author's most common categories, macros are set up with text string triggers in Keyboard Maestro (more on that below).
Certain strings have special meaning to timetracker. The category name in square brackets specifies that the task is related to a specific customer, or should be tracked on a certain item in Clarizen, to make transferring to Clarizen more straightforward. These can be any string, even with spaces, but beware of using shell special characters, or special regular expression characters. The names can be anything, so things like `[BB&T]`, `[Citi]`, `[Wells Fargo]`, or `[Internal]` are perfectly valid. For the author's most common categories, macros are set up with text string triggers in Keyboard Maestro (more on that below). If you decide to use `timetracker.py` (the Python 3 script), the category (in square-brackets) is optional, but won't have a separate section in `do_process.sh` (though it will reflect in the grand total at the end). If you decide to use the Rust programs, the category is **required**, or else the Rust programs will panic and error out. It is highly recommended to use the Rust programs, for speed if nothing else.
Note that the aggregate programs (`do_process.sh`, `doprocess` [Rust], `chug.sh`, `chug` [Rust]) expect the log file to be named by the ISO-8601 date format with the `.log` filename extension (e.g. `2017-06-09.log`, `2022-07-12.log`, `2022-12-19.log`), so it makes sense to keep only a single day's logs in one log file (since we're expected to load these times into Clarizen on a daily basis). However, there is nothing else in the code that makes this requirement (either Rust or Python/Bash scripts). In that case the aggregate programs will cover more than a day's worth of logs, which might make it difficult to transfer to Clarizen. Thus it is highly recommended to keep only a day's worth of logs in one log file. I recommend that if a task extends past midnight the next day, to End it at midnight in yesterday's log, and Begin it at midnight the next day's log.
An important point about this timetracker system: it automatically rounds the duration to the nearest quarter hour (nearest 15 minutes). If you document a task, but it takes less than 7.5 minutes from Begin to End, it's set to 0.08 hours (4 mintues, 48 seconds/288 seconds). Otherwise it would round down to 0.00hrs. If you don't want to count tasks that take so little time, you may want to remove them from the log. Previous versions of this system would round up to the nearest quarter hour, but I feared that was incorrectly inflating the amount of time I was spending during my day.
## timetracker in Rust
Again, see the [INSTALL.md](https://github.atl.pdrop.net/tblancher/timetracker/blob/master/INSTALL.md) guide in this repository for instructions on building the Rust programs. It is highly recommended to use the Rust programs instead of the older Python and Bash scripts below, if only because the Rust programs are much, much faster to execute than the older scripts. The usage is straightforward:
### timetracker usage
Pass the log name as the only argument to `timetracker`. Alternatively, you can execute a command pipeline that generates valid log output in the format above, piping it into timetracker:
```
timetracker 2022-12-19.log
grep 'Customer Name' 2022-12-19.log | timetracker
```
This will generate output similar to the following (using the above log file example as input):
```
[Cloud] Customer 1 PDROP-0000000 case-related task 1 0.75hrs
[Cloud] Customer 1 task 1 0.08hrs
[Cloud] Customer 2 task 2 1.50hrs
[Internal] documentation creation 2.75hrs
[Internal] email triage 0.75hrs
[Internal] internal task 1 0.25hrs
[Internal] internal task 2 0.25hrs
[On Prem] Customer 1 PDROP-0000000 case-related task 2 0.08hrs
[On Prem] Customer 3 external meeting 0.75hrs
Grand total: 7.16
```
This is the only Rust program that does not necessarily assume the log will be named in the ISO-8601 date format with `.log` filename extension (e.g. `2022-11-30.log`, `2022-12-19.log`, etc.). You can run this periodically throughout the day as you build the log file to see how much time you've put in thus far.
### doprocess usage
`doprocess` relies on the same internal Rust functions as `timetracker`, with the added output feature of separating the various categories into their own sections, for even easier transfer to Clarizen. With the new Clarizen categories, this makes entry into Clarizen take five minutes or less. You may want to sort your categories in Clarizen, to match the sort out of `doprocess`. Each section has its own total, with a running subtotal you can use to confirm you haven't missed anything as you transfer them to Clarizen. Its output looks like this:
```
[Cloud] Customer 1 PDROP-0000000 case-related task 1 0.75hrs
[Cloud] Customer 1 task 1 0.08hrs
[Cloud] Customer 2 task 2 1.50hrs
Section total: 2.33hrs
Subtotal: 2.33hrs
[Internal] documentation creation 2.75hrs
[Internal] email triage 0.75hrs
[Internal] internal task 1 0.25hrs
[Internal] internal task 2 0.25hrs
Section total: 4.00hrs
Subtotal: 6.33hrs
[On Prem] Customer 1 PDROP-0000000 case-related task 2 0.08hrs
[On Prem] Customer 3 external meeting 0.75hrs
Section total: 0.83hrs
Subtotal: 7.16hrs
Grand total: 7.16
```
For everything but the [Internal] category, you should be able to copy the entire section with Section total to a single line item in Clarizen. The Section total and Subtotal for the [Internal] category can be input as separate line items for each entry, and these totals help ensure you haven't missed one or input its duration improperly.
### chug usage
`chug` does not take a filename, or a log in the above format. Instead, it looks at the current week, and calculates the grand total for each day. If any day is missing, because the log file doesn't exist, it will print 0.00 for that day, like so:
```
2022-12-19.log
8.38
2022-12-20.log
0.00
2022-12-21.log
0.00
2022-12-22.log
0.00
2022-12-23.log
0.00
2022-12-24.log
0.00
2022-12-25.log
0.00
Grand total: 8.38
```
You can use this to review Clarizen, and make sure all time is input correctly. If you'd like to look at a previous week, you can pass the optional argument `1` or `+1`, `n` or `+n` where `n` is an unsigned integer for even further back. If you will be out of office on extended leave for the next week, and wish to run `chug` for it, pass a negative integer (e.g. `-1`, or `-n`). The formula for the week `chug` will look at is as follows:
```
<last Monday> - <week offset>
# where if offset is positive (either with or without a leading '+', it will look back). If the offset is negative it will look forward
# <last Monday> will be TODAY if today is Monday
```
## Caveats about Rust programs
The Rust programs have similar designs to the older Python and Bash scripts, but Rust is less forgiving regarding errors in the supplied logs (see format above). Namely, if you have too many Begin timestamps, or too many End timestamps, the Rust `timetracker`, `doprocess`, and `chug` programs will panic. They should give a hint as to why they panic, but there is automatic Rust output that may not make it obvious that there's a problem. For instance, with too many Begin timestamps, you'll see an error like the following:
```
thread 'main' panicked at 'Somehow, not a vector!', timelogging/src/lib.rs:88:60
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Unfortunately this doesn't tell you that you have a Begin without a corresponding End timestamp. Too many End timestamps unfortunately has a similar cryptic error. You'll need to review the log to ensure this doesn't happen. You can use the older Python or Bash scripts to help you find the culprit, if you need to.
# Older Python and Bash scripts, for comparison
## timetracker.py usage
The timetracker.py script is the basis, it tallies the time for each task and then outputs a report on how much each task takes to complete. It takes as its argument one or more text files, the log files in the format above. It should only report one line item per task, regardless of how many times it appears in the log. Each task should have a category/tag in square brackets, the behavior of `do_process.sh` (see below) is now undefined if the tag is left out.
@ -46,16 +153,16 @@ The output looks like this:
### timetracker output
```
[CS Support] documentation creation 3.00hrs
[CS Support] internal task 1 0.25hrs
[CS Support] internal task 2 0.50hrs
[Customer 1] PDROP-0000000 case-related task 1 1.00hrs
[Customer 1] PDROP-0000000 case-related task 2 0.25hrs
[Customer 1] task 1 0.08hrs
[Customer 2] task 2 1.75hrs
[Customer 3] external meeting 0.75hrs
[Productive Non-billable] email triage 0.75hrs
[Productive Non-billable] internal task 1 0.08hrs
[Internal] documentation creation 3.00hrs
[Internal] internal task 1 0.25hrs
[Internal] internal task 2 0.50hrs
[Cloud] Customer 1 PDROP-0000000 case-related task 1 1.00hrs
[Cloud] Customer 1 PDROP-0000000 case-related task 2 0.25hrs
[Cloud] Customer 1 task 1 0.08hrs
[Cloud] Customer 2 task 2 1.75hrs
[Cloud] Customer 3 external meeting 0.75hrs
[Internal] email triage 0.75hrs
[Internal] internal task 1 0.08hrs
Section total: 8.41hrs
```
@ -65,42 +172,42 @@ You may have noticed, the output of timetracker.py is in alphabetical order by c
This script filters the output of timetracker.py, giving each category (in square brackets) its own section, with its own tallies. The header is the list of categories and the log file basename (below this is `example.log`, but would normally be a date such as `2017-12-08.log`). After the header, each line of output and sections are designed to be directly transferred to Clarizen manually, and the tally used to verify the daily and weekly totals in Clarizen. It calculates the time total for each organization/category. It also prints the subtotal thus far, to be sure no items are missed when adding them to Clarizen. At the end it prints a grand total for the day, which should be used along with the subtotals to cross-verify in Clarizen.
```
[CS Support]
[Customer 1]
[Customer 2]
[Customer 3]
[Productive Non-billable]
[Internal]
[Cloud] Customer 1
[Cloud] Customer 2
[Cloud] Customer 3
[Internal]
--
example
[CS Support] documentation creation 3.00hrs
[CS Support] internal task 1 0.25hrs
[CS Support] internal task 2 0.50hrs
[Internal] documentation creation 3.00hrs
[Internal] internal task 1 0.25hrs
[Internal] internal task 2 0.50hrs
Section total: 3.75hrs
Subtotal: 3.75hrs
[Customer 1] PDROP-0000000 case-related task 1 1.00hrs
[Customer 1] PDROP-0000000 case-related task 2 0.25hrs
[Customer 1] task 1 0.08hrs
[Cloud] Customer 1 PDROP-0000000 case-related task 1 1.00hrs
[Cloud] Customer 1 PDROP-0000000 case-related task 2 0.25hrs
[Cloud] Customer 1 task 1 0.08hrs
Section total: 1.33hrs
Subtotal: 5.08hrs
[Customer 2] task 2 1.75hrs
[Cloud] Customer 2 task 2 1.75hrs
Section total: 1.75hrs
Subtotal: 6.83
[Customer 3] external meeting 0.75hrs
[Cloud] Customer 3 external meeting 0.75hrs
Section total: 0.75hrs
Subtotal: 7.58
[Productive Non-billable] email triage 0.75hrs
[Productive Non-billable] internal task 1 0.08hrs
[Internal] email triage 0.75hrs
[Internal] internal task 1 0.08hrs
Section total: 0.83hrs
Subtotal: 8.41hrs
@ -181,16 +288,16 @@ Several of the vim shortcuts I've programmed assist in managing the log text fil
Much of creating the log entries depends on specific Keyboard Maestro macros the author has set up. The file `timetracker.kmmacros` contains all of the macros used for this. The same text string trigger (Command + Shift + D, but you can assign it to any trigger) brings up a menu (known as a "conflict dialog" in KM), where I select '*B*egin' or '*E*nd'. The 'Begin' macro prints a log line using the current timestamp, like so:
```
2020-03-11 19:14:42: Begin [CS Support] timetracker doc
2020-03-11 19:14:42: Begin [Internal] timetracker doc
```
The 'End' macro copies the category and task name from the previous 'Begin' macro, to cut down on the amount of typing (and eliminate the possibility of typos). It then prints another 'Begin' line, ready for the next task. The output using the line above would look something like this:
```
2020-03-11 19:14:42: Begin [CS Support] timetracker doc
2020-03-11 19:30:36: End [CS Support] timetracker doc
2020-03-11 19:14:42: Begin [Internal] timetracker doc
2020-03-11 19:30:36: End [Internal] timetracker doc
2020-03-11 19:30:36: Begin
```
I also have Keyboard Maestro text string triggers for common categories, to minimize typing. For instance, the text string triggers `[css` becomes `[CS Support] `, `[pro` becomes `[Productive Non-billable] `, `[mm` or `[MM` becomes `[Mass Mutual] `, `[vzw` becomes `[Verizon Wireless] `, `[pin` becomes `[Company] ` (to match the Pindrop related items in Clarizen), etc. These are included in `timetracker.kmmacros` for your convenience.
I also have Keyboard Maestro text string triggers for common categories, to minimize typing. For instance, the text string triggers `[css` becomes `[Internal] `, `[pro` becomes `[Internal] `, `[mm` or `[MM` becomes `[Mass Mutual] `, `[vzw` becomes `[Verizon Wireless] `, `[pin` becomes `[Company] ` (to match the Pindrop related items in Clarizen), etc. These are included in `timetracker.kmmacros` for your convenience.
See [INSTALL.md](https://github.atl.pdrop.net/tblancher/timetracker/blob/master/INSTALL.md) in this repository for a detailed explanation of how to use the `timetracker.kmmacros` and set up the vim macros.