All Blogs

AIGHT: a Low-effort Productivity Tool

James Fenn |

AIGHT dlang.org


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. 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 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 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.

A terminal screen with AIGHT displaying a list of all the annoying bugs I need to fix.

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, 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.

[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 (to mark a task as “done” / remove it from the list) and aight stonks (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 - 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.