From 5d10c30fc5150ced04ebfcb1a9e100c43bef4762 Mon Sep 17 00:00:00 2001 From: Patrick Spek Date: Tue, 18 Jan 2022 15:39:07 +0100 Subject: Add missing articles from 2019 --- .../posts/2019/2019-02-03-how-to-sign-pgp-keys.md | 141 ++++++++++++++++ .../2019/2019-04-11-perl6-nightly-docker-images.md | 124 +++++++++++++++ .../2019-07-22-the-powerful-tooling-of-gentoo.md | 177 +++++++++++++++++++++ .../posts/2019/2019-08-10-the-soc-controversy.md | 99 ++++++++++++ .../2019-10-17-getting-things-done-with-app-gtd.md | 166 +++++++++++++++++++ content/posts/2019/_index.md | 3 + 6 files changed, 710 insertions(+) create mode 100644 content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md create mode 100644 content/posts/2019/2019-04-11-perl6-nightly-docker-images.md create mode 100644 content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md create mode 100644 content/posts/2019/2019-08-10-the-soc-controversy.md create mode 100644 content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md create mode 100644 content/posts/2019/_index.md diff --git a/content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md b/content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md new file mode 100644 index 0000000..d5f401a --- /dev/null +++ b/content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md @@ -0,0 +1,141 @@ +--- +title: How to sign PGP keys +date: 2019-02-03 +tags: +- PGP +- Tutorial +--- + +Having attended [FOSDEM](https://fosdem.org/2019/) last weekend, I have been +asked to help some people out with signing PGP keys. As it is an international +gathering of users and developers of all levels of expertise, it's a great event +to get your key out in to the wild. While helping people out, I figured it might +be even easier next time around to just refer to a small tutorial on my blog +instead. + +## Creating a PGP key + +The first step to sign keys, is to have a PGP key. If you already have one, +you're good to go to the next part of this tutorial. If you don't, you can check +out the `gpg` manual on how to create a key, or read about key creation in my +[article on using PGP with a Yubikey][yubikey-pgp-article]. While I would +strongly suggest reading at least some material, `gpg` does quite a good job of +guiding you through the process without prior knowledge, so you can just get +started with `gpg --generate-key` as well. + +[yubikey-pgp-article]: {{ "/post/2018/09/04/setting-up-pgp-with-a-yubikey/#creating-pgp-keys" | prepend: site.baseurl | prepend: site.url }} + +## Create key slips + +A *key slip* is a small piece of paper containing some basic information about +the PGP key. They're exchanged when people meet, so they don't have to +immediately sign the key, but can do it safely at home. When you're signing in a +group, this may be faster to work with. Another benefit is that some people +don't have their private keys with them. They can then just collect the key slips +from the people who's key they want to sign, and sign it whenever they are in +possession of their private key again. + +A key slip doesn't have to contain much. A key ID, fingerprint, email address and +a name is plenty. For reference, my key slips look as follows: + +```txt +Patrick Spek rsa4096/0x7A6AC285E2D98827 + 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 +``` + +## Verifying the owner + +Before you sign anyone's public key, you should verify that the person is +actually who they say they are. You can easily do this by asking for government +issued identification, such as an ID card, driver's license or passport. What +constitutes good proof is up to you, but in general people expect at least one +form of government issued identification. + +If the person can't verify who they are, you should *not* sign their key! + +## Retrieving their key + +Once you have verified the person is who they say they are, and you have +received their key slip containing their key ID, you can look up their key +online. You can let `gpg` do all the work for you in searching and downloading +the key, using the `--search` switch. For instance, to retrieve my key, do the +following: + +```txt +gpg --search-keys 0x7A6AC285E2D98827 +``` + +If a result has been found, you are prompted to enter the numbers of the keys +you want to download. Make sure you download the right key, in case multiple +have been found! + +After retrieving the key, you can see it in the list of all the keys `gpg` knows +about using `gpg --list-keys`. + +## Signing their key + +To actually sign their key, and show that you trust that the key belongs to the +person's name attached to it, you can use `gpg --sign-key`: + +```txt +gpg --sign-key 0x7A6AC285E2D98827 +``` + +You will be prompted whether you are sure you want to sign. You should answer +this with a single `y` to continue. + +After signing it, you'll have signed a PGP key! You can verify this by looking +at the signatures on a given key with `--list-sigs 0x7A6AC285E2D98827`. This should +contain your name and key ID. + +## Exchanging the signed key + +While you could publish the updated public key with your signature on it, you +should **not** do this! You should encrypt the updated public key and send it to +the person that owns the private key, and they should upload it themselves. One +reason for this is that it allows you to safely verify that they do in fact +actually own the private key as well, without ever asking them explicitly to +show you their private key. + +To export the public key, use `--export`: + +```txt +gpg --armor --export 0x7A6AC285E2D98827 > pubkey-tyil.asc +``` + +The `--armor` option is used to export the key as base64, instead of binary +data. + +You can attach this file to an email, and let your email client encrypt the +entire email and all attachments for they key ID. How you can do this depends on +your email client, so you should research how to do this properly in the +documentation for it. + +However, it's also possible to encrypt the public key file before adding it as +an attachment, in case you don't know how to let your email client do it (or if +you don't trust your email client to do it right). + +You can use the `--encrypt` option for this, and add a `--recipient` to encrypt +it for a specific key. + +```txt +gpg --encrypt --recipient 0x7A6AC285E2D98827 < pubkey-tyil.asc > pubkey-tyil.pgp +``` + +Now you can use this encrypted key file and share it with the owner of the key. +If the person you send it to really is the owner of the key, they can use the +private key to decrypt the file, import it with `gpg --import` and then publish +it with `gpg --send-keys` + +## Winding down + +Once all this is done, other people should have sent you your signed pubkey as +well, and you should have published your updated key with the new signatures. +Now you can start using PGP signatures and encryption for your communication +with the world. People who have not signed your key can see that there's other +people that do trust your key, and they can use that information to deduce that +whatever's signed with your key really came from you, and that anything they +encrypt with your public key can only be read by you. + +With this [trust](https://en.wikipedia.org/wiki/Web_of_trust), you can make +communication and data exchange in general more secure. diff --git a/content/posts/2019/2019-04-11-perl6-nightly-docker-images.md b/content/posts/2019/2019-04-11-perl6-nightly-docker-images.md new file mode 100644 index 0000000..61b54f5 --- /dev/null +++ b/content/posts/2019/2019-04-11-perl6-nightly-docker-images.md @@ -0,0 +1,124 @@ +--- +title: Perl 6 nightly Docker images +date: 2019-04-11 +tags: +- Perl6 +- Docker +- Raku +--- + +Due to the slow release of Rakudo Star (which actually did release a new +version last month), I had set out to make Docker images for personal use based +on the regular Perl 6 releases. But, as I discovered some [memory related +issues](https://github.com/rakudo/rakudo/issues/1501), and [another branch with +some possible fixes](https://github.com/MoarVM/MoarVM/pull/1072), I changed my +mind to make them nightlies based on the `master` branches of all related +projects instead. This way I could get fixes faster, and help testing when +needed. + +These nightlies are now up and running, available on [Docker +Hub](https://hub.docker.com/r/tyil/perl6) for anyone to use! You can also find +[the Dockerfiles I'm using on git.tyil.nl](https://git.tyil.nl/docker/perl6), +in case you're interested or have suggestions to further improve the process. + +The timing of the (public) release of these images could have been better, +though. About two weeks ago, other nightlies were released as well, by Tony +O'Dell, as has been noted in the [Perl 6 Weekly +post](https://p6weekly.wordpress.com/2019/03/25/2019-12-cool-truck/). While I +greatly appreciate his efforts, I was not going to just abandon all the work +I've put into my images. Instead I've tried to make smaller images, and provide +different bases than him. Maybe we can eventually learn from each other's images +and improve Docker support for the entire community together. + +The easiest thing to work on was providing different bases. For now, this means +I have images with the following four base images: + +- Alpine +- Debian +- Ubuntu +- Voidlinux + +This way, people can have more options with regards to using the distribution +tooling that they're more comfortable with. One could also opt to use a more +familiar or better supported base image for development and testing out their +module, and use a smaller image for production releases. + +As to the size of the images, Tony's `tonyodell/rakudo-nightly:latest` is about +1.42GB at the time of writing this post. My images range from 43.6MB +(`alpine-latest`) to 165MB (`voidlinux-latest`). Though this is not a +completely fair comparison, as my images have stripped out a lot of the tooling +used (and often required) to build some Perl 6 modules, making them unusable in +their default shape for many projects. + +To remedy this particular issue, I've also created *-dev* images. These images +come with a number of additional packages installed to allow `zef` to do its +work to get dependencies installed without requiring end-users to search for +those packages. This should reduce complexity when using the images for +end-users. If we take the dev images into account when comparing sizes, my +images range from 256MB (`alpine-dev-latest`) to 1.27GB +(`voidlinux-dev-latest`). That's much closer to the `rakudo-nightly` image. + +If you're interested in trying these images out, you may be interested in the +way I'm using these images myself as reference. Currently, my [CPAN upload +notifier bot](https://git.tyil.nl/perl6/app-cpan-uploadannouncer-irc) is using +these nightly images in its +[`Dockerfile`](https://git.tyil.nl/perl6/app-cpan-uploadannouncer-irc/src/branch/master/Dockerfile). + +```Dockerfile +FROM tyil/perl6:debian-dev-latest as install + +RUN apt update && apt install -y libssl-dev uuid-dev + +COPY META6.json META6.json + +RUN zef install --deps-only --/test . +``` + +As you can see from the `Dockerfile`, I start out by using a `-dev` image, and +name that stage `install`. I'm still contemplating to include `libssl-dev` into +the `-dev` images, as it seems to pop up a lot, but for now, it's not part of +the `-dev` images, so I install it manually. Same goes for `uuid-dev`. Then I +copy in the `META6.json`, and instruct `zef` to install all the dependencies +required. + +```Dockerfile +FROM tyil/perl6:debian-latest + +ENV PERL6LIB=lib + +WORKDIR /app + +RUN mkdir -p /usr/share/man/man1 +RUN mkdir -p /usr/share/man/man7 +RUN apt update && apt install -y libssl-dev postgresql-client + +COPY bin bin +COPY lib lib +COPY --from=install /usr/local /usr/local + +RUN mkdir -p /var/docker/meta +RUN date "+%FT%TZ" > /var/docker/meta/build-date + +CMD [ "perl6", "bin/bot" ] +``` + +Then I start a new stage. I set the `$PERL6LIB` environment variable so I don't +have to use `-Ilib` at the end, and set a `WORKDIR` to have a clean directory +to work in. Next, I set up the *runtime dependencies* of the application. + +I then continue to copy in the `bin` and `lib` directories, containing the +application itself, and copy over `/usr/local` from the `install` stage. +`/usr/local` is where Perl 6 is installed, and `zef` installs all its +dependencies into. This way, the `-dev` image can be used for building all the +dependencies as needed, and only the finished dependencies end up in the final +image that's going to run in production. + +Lastly, I set the build date and time of the image in a file, so the +application can refer to it later on. It is displayed when the IRC bot replies +to a `.bots` command, so I can verify that the running bot is the one I just +built. And finally, the `CMD` instruction runs the application. + +I hope this displays how the images can be used for your applications, and the +reasoning as to why I made them the way they are. If you have any suggestions +or issues, feel free to contact me in whatever way suits you best. You can find +some contact details on the homepage of my blog. diff --git a/content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md b/content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md new file mode 100644 index 0000000..9d8cff2 --- /dev/null +++ b/content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md @@ -0,0 +1,177 @@ +--- +title: "The Power(ful Tooling) of Gentoo" +date: 2019-07-22 +tags: +- Gentoo +--- + +People often ask me for my reasons to use [Gentoo](https://gentoo.org/). Many +perceive it as a "hard" distro that takes a lot of time. While it does come +with a learning curve, I don't perceive it as particularly "hard", as the +documentation is very thorough and the community is very helpful. And the +tooling you get to maintain your system is far beyond what I've come across +with any other GNU+Linux distribution. + +This blog post will highlight some of the key features I love about Gentoo. +There are certainly many more perks that I don't (yet) use, so please feel free +to inform me of other cool things that I missed. + +## Configurability + +One of the main reasons for preferring Gentoo is due to the ease of configuring +it to work just the way you want. + +A great example for this would be with `init` choices. Many distributions only +support [systemd](https://en.wikipedia.org/wiki/Systemd) these days. As I'm not +a big fan of this particular system, I want to change this. But even asking a +question about this will get you a lot of hatred in most distribution +communities. In Gentoo, however, changing init is supported and well +documented, allowing you to pick from a range of possible inits. + +### `USE` flags + +One of the core concepts of Gentoo are the [`USE` +flags](https://wiki.gentoo.org/wiki/USE_flag). These allow you to easily alter +the software you're compiling to use the features you want. They can also be +used to indicate which library you would like to use to make use of a certain +feature, if there are multiple implementations available. + +### `make.conf` + +Like most distros that work with self-compiled packages, Gentoo has a +`make.conf` file available to specify some default arguments in to use while +compiling. Unlike most other distros, Gentoo's `make.conf` also allows for some +configuration of the `emerge` utility. + +For instance, I use my `make.conf` to ensure `emerge` always asks for +confirmation before performing actions. I also ensure that the build system, +`portage`, is heavily sandboxed when building packages. + +Additionally, like all configuration files in `/etc/portage`, it can be made +into a directory. In this case, all files in the directory will be loaded in +alphabetical order. This allows for easier management using tools like +[Ansible](https://www.ansible.com/). + +### Ease of patching + +Another feature I find very useful of Gentoo, is the ease of applying my own +patches to software. If you have a custom patch for a package that you want to +be applied, all you have to do is drop it in a directory in +`/etc/portage/patches`. The directory is should be in is the same as the +package's name the patch is intended for. For instance, I have the following +patch in `/etc/portage/patches/www-client/firefox`: + +```diff +diff --git a/browser/extensions/moz.build b/browser/extensions/moz.build +index 6357998..c5272a2 100644 +--- a/browser/extensions/moz.build ++++ b/browser/extensions/moz.build +@@ -5,15 +5,10 @@ + # file, You can obtain one at http://mozilla.org/MPL/2.0/. + + DIRS += [ +- 'activity-stream', + 'aushelper', + 'followonsearch', + 'formautofill', + 'jaws-esr', +- 'onboarding', +- 'pdfjs', +- 'pocket', +- 'screenshots', + 'webcompat', + ] +``` + +Whenever a new Firefox is released and built, this patch will be applied on it +to remove some of the features I dislike. + +## Ebuilds and overlays + +In Gentoo vocabulary, `ebuild` files are the files that describe how a package +is to be built, which `USE` flags it supports and everything else relating to a +package. An overlay is a repository of ebuild files. Everyone can make their +own, and easily add 5 lines in their `repos.conf` to use it. In most cases, +they're just git repositories. + +The documentation on everything around ebuilds is superb, in my experience, +especially compared to other distros. It is incredibly easy to get started +with, since it's made to be usable with very little effort. While being simple, +it's also very flexible: All default behaviours can be overwritten if needed to +get a package to build. + +## Binary packages + +Yes, you read that right. [Binary +packages](https://wiki.gentoo.org/wiki/Binary_package_guide)! Contrary to +popular belief, Gentoo *does* support this. You can instruct `emerge` to build +binary packages of all the packages it compiles, which can then be re-used on +other systems. It does need to be compiled in such a way that the other machine +can use it, of course. You can't simply exchange the packages of an x64 machine +with and ARM machine, for instance. You can set up a [cross build +environment](https://wiki.gentoo.org/wiki/Cross_build_environment) to get that +particular usecase going, though. + +If you want to easily share the binary packages you build with one machine, you +can set up a +[binhost](https://wiki.gentoo.org/wiki/Binary_package_guide#Setting_up_a_binary_package_host), +and have `emerge` pull the binary packages on the other systems as needed using +`--usepkg`. There actually is a [binhost provided by Gentoo +itself](http://packages.gentooexperimental.org/), but it seems to only contain +important packages used to restore systems into a working state. + +## Tooling + +Some of the core tooling available to any Gentoo user has already been talked +about. But there's some additional tooling you can install to make your life +even better. + +### `genkernel` + +One of the hardest tasks to newcomers to Gentoo is often to compile a kernel. +Of course, Gentoo has an answer for this, `genkernel`. The defaults `genkernel` +will give you are reasonably sane if you just want to have a kernel that works. +Of course, you can still edit the kernelconfig before compilation starts. It +will also build an `initramfs` when requested, that goes along with the kernel. +When things have been made, the kernel and initramfs will be moved to `/boot`, +and a copy of the working kernelconfig is saved to `/etc/kernels`. All you need +to remember is to update your preferred bootloader's configuration to include +your new kernel. + +### `eix` + +[`eix`](https://wiki.gentoo.org/wiki/Eix) is a utility most Gentoo users use to +update the Portage repositories and search for available packages. The +interface is considered more convenient, and it's a bit faster at getting your +results. + +To get a quick overview of which packages are in need of updates, you can run +`eix -uc` (*u*pdates, *c*ompact). To sync the Portage tree and all overlays, +`eix-sync` is the way to go. This will ensure the cache used by `eix` also gets +updated. + +In addition to having a cleaner interface and being faster, it also comes with +additional tools for keeping your system sane. The most notable to me is +`eix-test-obsolete`. + +This utility will report any installed packages that are no longer provided by +any repository (orphaned packages). It will also report all configuration lines +that affect such packages. This is really valuable in keeping your +configuration maintainable. + +### `glsa-check` + +The `glsa-check` utility is part of the `app-portage/gentoolkit` package. When +ran, it will produce a list of all packages which have known vulnerabilities. +It will use the [GLSA database](https://security.gentoo.org/glsa) for the list +of known vulnerabilities. This can be much easier than subscribing to a mailing +list and having to check every mail to see if a vulnerability affects you. + +### `qlop` + +`qlop` is another utility that comes with `app-portage/gentoolkit`. This +program parses the logs from `emerge` to give provide you with some +information. I use this mostly to see compile times of certain packages using +`qlop -Htvg `. Using this, I can more easily deduce if I want my +desktop (with a stronger CPU) to compile a certain package, or if it'll be +faster to just compile it on my laptop. diff --git a/content/posts/2019/2019-08-10-the-soc-controversy.md b/content/posts/2019/2019-08-10-the-soc-controversy.md new file mode 100644 index 0000000..762492d --- /dev/null +++ b/content/posts/2019/2019-08-10-the-soc-controversy.md @@ -0,0 +1,99 @@ +--- +title: The SoC Controversy +date: 2019-08-10 +tags: +- CodeOfConduct +- Conference +- Perl6 +- Raku +--- + +{{< admonition title="Disclaimer" >}} +{% admonition_md Disclaimer %} +Please keep in mind that the opinion shared in this blog post is mine and mine +alone. I do not speak for any other members of the PerlCon organization team. +Please do not address anyone but me for the positions held in this post. +{{< / admonition >}} + +Those that know me are probably aware that I generally dislike to make +political posts on my personal blog. I'd rather stick to technological +arguments, as there's less problems to be found with regards to personal +feelings and all that. However, as I'm growing older (and hopefully more +mature), I find it harder to keep politics out of my life as I interact with +online communities. This becomes especially true as I plan to assist with +organizing [PerlCon +2020](https://wiki.perlcon.eu/doku.php/proposals/2020/amsterdam). + +PerlCon 2019 ended yesterday, and I had a lot of fun. I'd like to thank the +organizer, Andrew Shitov, once more for doing an amazing job. Especially so, as +he has been harassed for weeks, for trying to organize the conference. The +reason behind the harassment was partly due to his decision to not have an SoC, +or "Standards of Conduct", for PerlCon 2019. + +During his final announcements at the end of the conference, he noted that this +is still happening, even in person at the conference itself. This toxic +behavior towards him has made him decide to no longer involve himself in +organizing a conference for the Perl community. I personally think this is a +loss for everyone involved in the community, and one that was completely +avoidable by having humane discussion instead of going for Twitter harassment. + +For what it's worth, I think Twitter is also the worst possible place on the +Internet for any reasonable discussion, as it puts a very low limit on the +amount of characters you are allowed to spend on a single post. This makes it +downright impossible for any discussion, and seems to always lead to petty +name-calling. This is one of the reasons why [I'm instead using a Pleroma +instance](https://soc.fglt.nl/main/public) for my social media presence on the +Internet. If anyone is on the Internet with the intent of having interesting +discussion, I'd highly recommend to use some entrance into the Fediverse. The +instance I'm using is open for sign-ups! + +But I digress. The SoC controversy is what made me want to write this blog +post. I wonder why this even is a controversy. Why do people think it is +impossible to co-exist without some document describing explicitly what is and +is not allowed? I would hope that we're all adults, and can respect one another +as such. + +I wonder, was there any certain event at PerlCon 2019 that would've been +avoided if there *was* a SoC provided? I certainly did not, at any point, feel +that people were being harmful to one another, but maybe I'm just blind to it. +If anyone has concrete examples of events that happened during PerlCon 2019 +that a SoC could've prevented, I would be genuinely interested in hearing about +them. If I am to assist in organizing PerlCon 2020, and I want to be able to +present a good argument on the SoC discussion, I'll need concrete examples of +real problems that have occurred. + +Of course, I also consider the opposite of this discussion. Can the SoC be used +to *cause* harm, in stead of deter it? For this, I actually have clear +evidence, and the answer is a resounding **yes**. The harassment brought upon +Andrew was originally caused by an event that transpired at The Perl Conference +in Pittsburgh (2019). A video was removed, and a speaker harassed, for +dead-naming someone. Until that event, I wasn't even aware of the term, but +apparently it's grounds for removal of your presentation from the conference +archives. + +A similar event happened with The Perl Conference in Glasgow (2018), where a +talk was also removed from the archives for a supposedly offensive joke that +was made. This also sparked a heavy discussion on IRC back then, with people +from all sides pitching in with their opinion. + +From my perspective, the people shouting the loudest in these discussions +aren't interested in making the world a better place where we can live in +harmony, but to punish the offender for their behavior. I don't think we +should strive towards punishment, but towards understanding, if anything. Just +being angry, shouting at people (either in real life, or over the Internet) +isn't going to solve any underlying problem. It is more likely to cause more +issues in the long run, where people will just be more divided, and will want +to get continuous revenge upon the other side. + +Additionally, I think that the existence of an SoC or likewise document is a +sign towards outsiders that your community can't behave itself maturely. They +need special rules laid out to them, after all. Like most rules, they are +codified because issues have arisen in the past, and keep on arising. I don't +think the Perl community is too immature to behave itself. I trust in the good +faith of people, and to me it feels like a SoC does the exact opposite. + +I hope this blog post does it's job to invite you kindly to share your opinions +with me, either on [IRC, email or on the Fediverse](/#contact). I'd +gladly start a discussion on the positive and negative effects the SoC has, and the problems +it solves and creates. I think a civil discussion is in order here, to best +prepare us for PerlCon 2020. diff --git a/content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md b/content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md new file mode 100644 index 0000000..0a24e57 --- /dev/null +++ b/content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md @@ -0,0 +1,166 @@ +--- +title: "Getting Things Done with App::GTD" +date: 2019-10-07 +tags: +- GettingThingsDone +- Perl6 +- Raku +--- + +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. + +## The problem + +The tools that were introduced did their job, and looked reasonably shiny. +However, 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. + +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. + +## 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 its 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. + +{{< admonition title="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. +{{< / admonition >}} + +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`. + +## 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! + +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. + +```txt +gtd add Buy eggs +gtd add "update cpan-raku's help command" +``` + +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. + +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. + +```txt +$ gtd inbox +[1] Buy eggs (2019-10-17) +[2] update cpan-raku's help command (2019-10-17) +``` + +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. + +```txt +$ 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. +``` + +You can now see that your inbox is empty when using `inbox`, and see a list of +the next items you created with `next`. + +```txt +$ 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) +``` + +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. + +```txt +$ 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! +``` + +## 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! diff --git a/content/posts/2019/_index.md b/content/posts/2019/_index.md new file mode 100644 index 0000000..b69640f --- /dev/null +++ b/content/posts/2019/_index.md @@ -0,0 +1,3 @@ +--- +title: 2019 +--- -- cgit v1.1