|
|
@@ -1,111 +0,0 @@ |
|
|
|
--- |
|
|
|
layout: layouts/blog |
|
|
|
title: "AIGHT: a Low-effort Productivity Tool" |
|
|
|
description: "AIGHT is a command-line tool for getting todo tasks quickly." |
|
|
|
date: "2020-02-27" |
|
|
|
links: |
|
|
|
- name: AIGHT |
|
|
|
url: https://code.horrific.dev/spb/aight |
|
|
|
- name: dlang.org |
|
|
|
url: https://dlang.org/ |
|
|
|
tags: blog |
|
|
|
--- |
|
|
|
|
|
|
|
Recently, I've taken a bit of time off from my Android projects to try out a few |
|
|
|
different languages and styles of development, and this one in particular is a |
|
|
|
tool that I've co-authored with [Sean Bailey](https://www.spb.li/). Since it's |
|
|
|
approaching a semi-stable stage of development, I thought I'd make a short post |
|
|
|
to highlight its functionality and our reasons for writing it. |
|
|
|
|
|
|
|
The idea originated from Sean - they often perform an arbitrary action in their |
|
|
|
terminal between tasks or when they've run out of ideas: they type the word |
|
|
|
`aight`. Of course, this doesn't have any particular use; it just prints "bash: |
|
|
|
aight: command not found" on the screen, but it functions as a transition |
|
|
|
between different items and tasks that they need to accomplish. Sean had the |
|
|
|
idea to write [a bash script](https://code.horrific.dev/spb/aight/src/commit/c6fab72a6019fc1ea2ef0219c793950cf74ab69a/AIGHT.sh) |
|
|
|
that would print out their tasks from Trello each time they type this, to |
|
|
|
instead show them what they need to do next and hopefully improve their |
|
|
|
productivity. |
|
|
|
|
|
|
|
I jumped on board with this pretty easily; I was looking for an excuse to try |
|
|
|
out [dlang](https://dlang.org/) in a larger project, and this sounded like a |
|
|
|
good excuse to do so - there's a lot of potential functionality to expand upon, |
|
|
|
such as displaying different tasks in a different directory, or adding support |
|
|
|
for different task or todo-like services. It also gave me the opportunity to |
|
|
|
work on something with other people - we are now a group of three people |
|
|
|
collaborating on one project. It's incredibly helpful and satisfying to be able |
|
|
|
to discuss features and implementation with others, have meaningful code |
|
|
|
reviews, and learn from each other as we approach a problem. |
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
## Structure |
|
|
|
|
|
|
|
This might be the first program I've written where I'm still satisfied with the |
|
|
|
structure of the program a month after writing it, if that says anything. |
|
|
|
However, the actual vocabulary used in the codebase is... confusing, at best. |
|
|
|
Most of the core functionality is defined in "providers", which are essentially |
|
|
|
different implementations of the functionality for accessing and modifying the |
|
|
|
tasks that can be provided by a service. There's one provider implementation for |
|
|
|
Trello, one for GitHub issues, one for GitLab, etc... |
|
|
|
|
|
|
|
The program starts by searching through an INI-like |
|
|
|
[configuration file](https://code.horrific.dev/spb/aight#user-content-configuration), in |
|
|
|
which a "group" (the syntax starting from the provider `[name]` in brackets |
|
|
|
until the next empty line) represents a "rule" for a provider, or a particular |
|
|
|
situation in which a provider should be used. These rules will be read in order |
|
|
|
until the conditions of the rule are met; namely, the current directory and the |
|
|
|
current git repo can be set as requirements for a rule to be used. If a rule is |
|
|
|
valid, the program will instantiate its provider with the provided parameters in |
|
|
|
the rule and perform the action it was started for. |
|
|
|
|
|
|
|
```ini |
|
|
|
[trello] |
|
|
|
matchRemote=git@github.com:fennifith/* |
|
|
|
trelloApiKey=yeet |
|
|
|
trelloApiToken=yeet |
|
|
|
trelloBoardId=yeet |
|
|
|
``` |
|
|
|
|
|
|
|
This terminology is not particularly user-friendly and could use some |
|
|
|
improvement as the project grows; knowing what someone is referencing when they |
|
|
|
say "provider" or "service" or "rule", and that they're all distinct things, is |
|
|
|
a bit of an issue for a user that shouldn't need to know about the program's |
|
|
|
internal functionality. |
|
|
|
|
|
|
|
## Interface |
|
|
|
|
|
|
|
The simplest interaction with the CLI is simply running `aight` as a command - |
|
|
|
using whatever provider is specified in your configuration, it will output a |
|
|
|
table or list of the "tasks" it finds. The list also contains an ID number for |
|
|
|
each task which can be used to reference it in other commands - for example, to |
|
|
|
get more information about task #3: `aight show 3`. |
|
|
|
|
|
|
|
To view a list of the rules in the configuration file (helpful for debugging or |
|
|
|
verifying conditions), `aight list-providers` will display all active & inactive |
|
|
|
provider rules. |
|
|
|
|
|
|
|
There are also various other commands being planned, such as |
|
|
|
[`aight yeet`](https://code.horrific.dev/spb/aight/issues/4) (to mark a task as |
|
|
|
"done" / remove it from the list) and |
|
|
|
[`aight stonks`](https://code.horrific.dev/spb/aight/issues/19) (to show |
|
|
|
statistics about previously closed tasks). |
|
|
|
|
|
|
|
## D Language |
|
|
|
|
|
|
|
D-lang was definitely a good choice for this project - it's almost like a middle |
|
|
|
ground between C and NodeJS, where it can interact with system libraries and |
|
|
|
functionality at a pretty low level but still have useful tooling and |
|
|
|
quality-of-life features similar to node: a package manager for libraries, good |
|
|
|
documentation, easy integration with CI & unit testing... |
|
|
|
|
|
|
|
Their website also has a lot of well-written tutorials that make it much easier |
|
|
|
to get started with as a newcomer, and there's a good collection of libraries |
|
|
|
built for it (along with the existing C/C++ libraries it can bind to). |
|
|
|
|
|
|
|
## "aight install" |
|
|
|
|
|
|
|
Currently, `aight` is only available to install by compiling directly from the |
|
|
|
[source code](https://code.horrific.dev/spb/aight) - but we have plans to |
|
|
|
distribute it through other package repositories like Homebrew and Arch Linux's |
|
|
|
AUR. I'll update this blog when that happens. |