Quest: #2 — A tool to automate documentation

Quest began as an idea to have a CLI app that would help developers quickly create notes or to-dos directly from the terminal where they already spend a lot of time running all sorts of commands such as “dotnet run”, “go build”, “git commit”, “ng s”, “cargo run”, etc. As a developer, one thing that really bothers me is having to go search for a directory, file, or app just to save a note or to-do, I would love to be able to do that from the terminal.

Contribute or Create?

After a quick search, I found that there were already some CLI apps in GitHub doing things like saving notes. That was cool and disappointing at the same time. Cool because it was nice to see that other people were having similar ideas, but disappointing because I wanted to create something new and original.

So I was having to decide between contributing to these existing projects or spending more time thinking about something new. Although I really want to have the experience of contributing to OSS projects, I chose to invest time on my own project for a couple of reasons:

• More experience: Before contributing code to other projects, I first wanted to improve my programming skills and learn more.
• New languages: At the time of writing this post I had 3 years of experience writing C# code, and a couple of months writing Go. I wanted to learn Ruts and Elixir.
• A new idea: I also had an idea that I though was simple but relatively new. And that’s what I’m describing next.

Quest: A CLI “kanban” Tool

As I was thinking about something that would help developers in general it became hard to have an original idea because I did not have a good insight into everyone’s experiences, so I shifted my focus and started thinking about what would help me in my daily work.

And that’s when I had the idea to create a CLI tool that would save to-dos in a way that would also help with the documentation of applications I write. And this is the (relatively) new idea:

Quest will be a CLI app that gets a to-do input from the user and saves that to a “todo.md” file in the same Git repo of the software it refers to. For example, say a developer is writing a web app and has to create a new UI component. He can save that to-do by running a command similar to this:

$ quest do “Create UI component for downloads”

That command will save that string the the Markdown file “todo.md”.

When that task is complete, the developer can run the following command:

$ quest done (an identification)

And that action will save the completed “to-do” in a different file: “done.md”

In order to make Quest work properly and as simple and friendly to developers as possible there are a lot of details that I will cover in future posts.

The Outcome

The outcome is having the tasks necessary to have an application working documented in the same repository as the source code. This will allow future developers to easily find what is happening in the source code. Also, the “to-dos” become decoupled from external platforms, but can optionally be integrated with them.