summaryrefslogtreecommitdiff
path: root/_posts
diff options
context:
space:
mode:
authorPatrick Spek <p.spek@tyil.nl>2019-10-17 16:56:50 +0200
committerPatrick Spek <p.spek@tyil.nl>2019-10-17 16:56:50 +0200
commit9fa36fa01300cf95d78e7591d8c02f88a6f0a0dd (patch)
treea66e9e586fd9a611532204617ca7c85a6f59c7db /_posts
parentdb80e6b78a5dd7799a34c5e929a3599c040145a5 (diff)
Add new blogpost on App::GTD
Diffstat (limited to '_posts')
-rw-r--r--_posts/2019-10-17-getting-thigs-done-with-app-gtd.html194
1 files changed, 194 insertions, 0 deletions
diff --git a/_posts/2019-10-17-getting-thigs-done-with-app-gtd.html b/_posts/2019-10-17-getting-thigs-done-with-app-gtd.html
new file mode 100644
index 0000000..933d9d8
--- /dev/null
+++ b/_posts/2019-10-17-getting-thigs-done-with-app-gtd.html
@@ -0,0 +1,194 @@
+---
+title: Getting Things Done with App::GTD
+layout: post
+tags: Perl Perl6 Raku GTD GettingThingsDone
+description: >
+ My $day-job has introduced me to this concept of "Getting Things Done", and I
+ have been convinced to give it a shot. However, I could not find a good free
+ software program to assist me with following this lifestyle. Thus I brought
+ App::GTD to the world.
+---
+
+{% markdown %}
+A couple months ago, I was given a workshop at work about "getting things
+done". There I was told that there exists a concept called "[Getting Things
+Done](https://en.wikipedia.org/wiki/Getting_Things_Done)", or "GTD" for short,
+to help you, well, get things done. A number of web-based tools were introduced
+to assist us with following the rules laid out in the concept.
+{% endmarkdown %}
+
+{% markdown %}
+## The problem
+
+The tools that were introduced did their job, and looked reasonably shiny.
+However, and most required a constant Internet connection. I like my tools to
+be available offline, and optionally synced together. There was one local
+application and a couple cloud-synced applications that I found, so this
+problem could've been resolved. However, my other problem with all these
+programs was that they're all proprietary. Those who've read more of my blog
+may have realized by now that I strongly prefer free software whenever
+possible.
+{% endmarkdown %}
+
+{% markdown %}
+Being unable to find any free software programs to fulfill my needs, I took a
+look at the features I would need, and tried to adapt other programs to fit
+those particular needs. I quickly learned that it's inconvenient at best to try
+and mold generic task keeping programs into the specifics of GTD. But, it did
+give me a reasonable idea of what features I needed for basic usage. It
+occurred to me that it shouldn't be terribly hard to just write something of my
+own. So I did.
+{% endmarkdown %}
+
+{% markdown %}
+## The solution, `App::GTD`
+
+Introducing [`App::GTD`](https://gitlab.com/tyil/raku-app-gtd), a brand new
+project written in the [Raku programming language](https://raku.org/). While
+still in its early phases, it seems to be usable on a day-to-day basis for me
+and another colleague. In it's bare basics, it's just another to-do list, but
+the commands it gives you incorporate the concepts of GTD. There's an inbox
+that you fill up through the day, a list of next items to work on, and projects
+to structure larger tasks in.
+{% endmarkdown %}
+
+{% admonition_md Note %}
+The Raku programming language used to be called the Perl 6 programming
+language. They function the same, but the name was changed for various reasons
+I will not get into here.
+{% endadmonition_md %}
+
+{% markdown %}
+This program can be installed using `zef`, though I'm planning an `ebuild` for
+Gentoo (and derivatives) too. Once installed, you can use `gtd` from your
+shell. Doing so without arguments will show the usage information. The most
+important will be `gtd add`, `gtd next` and `gtd done`. Most of these commands
+require an `id` argument. The IDs required are displayed in front of the items
+when listing them with commands like `inbox` or `next`.
+{% endmarkdown %}
+
+{% markdown %}
+## Daily life with `gtd`
+
+Once you have `gtd` installed, you don't *need* to do any configuration, as the
+defaults should work fine for most people. This means you can start using it
+immediately if you want to try it out!
+{% endmarkdown %}
+
+{% markdown %}
+The most common invocation will be with the `add` sub-command. Whenever
+something pops up that needs doing, you add it to your inbox using it.
+{% endmarkdown %}
+
+{% highlight sh %}
+gtd add Buy eggs
+gtd add "update cpan-raku's help command"
+{% endhighlight %}
+
+{% markdown %}
+These items go to your inbox, and don't need to be long, so long as *you*
+understand what you meant by it. You can see that you also don't need to use
+quotes around the item you want to add. All arguments after `add` will be
+joined together as a string again, but some shells may perform their magic on
+certain things. This is why I quoted the second call, but not the first.
+{% endmarkdown %}
+
+{% markdown %}
+All these things that you write down like this need to be sorted out at some
+point. I do this every day in the morning, before I get to my regular tasks at
+work. To get started, I want to see an overview of your inbox, for which the
+`inbox` sub-command is intended. Running it will give you a list of all the
+items in your inbox, including their ID and the date they were added.
+{% endmarkdown %}
+
+{% highlight text %}
+$ gtd inbox
+[1] Buy eggs (2019-10-17)
+[2] update cpan-raku's help command (2019-10-17)
+{% endhighlight %}
+
+{% markdown %}
+Now I can go through the list, and decide which actions I should undertake
+specifically. These are called "next items", and the sub-command is named
+`next`. Called without arguments it will give you an overview of your next
+items, but when given an ID it will move an inbox item to your list of next
+items. You can optionally also specify a new name for the item, to be more
+clear about what needs doing.
+{% endmarkdown %}
+
+{% highlight text %}
+$ gtd next
+You're all out of Next actions!
+
+$ gtd next 1
+"Buy eggs" has been added as a Next item.
+
+$ gtd next 2 "Add usage and repo info to cpan-raku, whenever it's messaged with 'help'"
+"Add usage and repo info to cpan-raku, whenever it's messaged with 'help'" has
+been added as a Next item.
+{% endhighlight %}
+
+{% markdown %}
+You can now see that your inbox is empty when using `inbox`, and see a list of
+the next items you created with `next`.
+{% endmarkdown %}
+
+{% highlight text %}
+$ gtd inbox
+Your inbox is empty!
+
+$ gtd next
+[1] Buy eggs (2019-10-17)
+[2] Add usage and repo info to cpan-raku, whenever it's messaged with 'help' (2019-10-17)
+{% endhighlight %}
+
+{% markdown %}
+Now all that's left is to do all the things you've created next items for. When
+done, you can remove the entry from your next items using `done`. This command
+also works on items in your inbox, so small tasks that require no next item(s)
+can be marked as done immediately.
+{% endmarkdown %}
+
+{% highlight text %}
+$ gtd done 1
+"Buy eggs" has been removed from your list.
+
+$ gtd done 2
+"Add usage and repo info to cpan-raku, whenever it's messaged with 'help'" has
+been removed from your list.
+
+$ gtd next
+You're all out of Next actions!
+{% endhighlight %}
+
+{% markdown %}
+## Future plans
+
+The basics are here, but there are some things I'd very much like to add. First
+and foremost, I want to be have a context to add to items, and a single context
+the program operates in. This way, I can more clearly separate work and
+personal tasks, which now just share one global context.
+
+Additionally, I've read about a new YouTube tutorial about using `ncurses` in
+Raku, which I hope can guide me through making an `ncurses` application for
+this as well. Perhaps I can find time to make a `GTK` application out of it as
+well.
+
+I've already mentioned wanting to create a Gentoo `ebuild` for the application,
+but this will require packaging all the module dependencies as well. This comes
+with a number of hurdles that I'm trying to iron out before starting on this
+endeavor. If you are on Gentoo (or a derivative) and want to assist in any way,
+please contact me.
+
+Another thing I've taken into account when structuring the application is the
+possibility for other data back-end. `gtd` is currently storing it's
+information in `JSON` files in a filesystem directory, which comes with various
+drawbacks. It may be beneficial to also support databases such as SQLite or
+PostgreSQL. However, this is not a high priority for me right now, as it would
+slow down the speed at which I can make improvements to the general program.
+
+I hope that `App::GTD` can help others to get things done as well. The program
+is all but finished, but it should be usable for people besides me and my
+colleague by now. If you have any suggestions or questions about the program,
+do not hesitate to seek me out!
+{% endmarkdown %}