#Tools

I mentioned a few posts back that I’m convinced the underlying database for my life really needs to be plain text files. Simplicty works. But, it’s surprising how few tools seem to be based on this idea.

I’d ignored Obsidian after initially checking it out because it had no live preview feature and having two panes open on a laptop took up too much real estate. Them adding the single in-editor live preview feature has completely changed my experience since I’ve hit a sweet spot between writing experience, bi-directional linking, and task management along with it being simple markdown files I control. Things painful or messy in other apps work smoothly. I’m also shocked at how good thier plugin ecosystem is already, allowing me to layer on functionality I want and not have any bloat I don’t need.

I’m convinced now that the underlying database for my life needs to move longer-term to human-readable, plain-text formats. As much as practical. And files under my control. But, it’s hard being an OG when everyone is shouting cloud. How do you do it? Why would you do it?

Sounds old school, I know… but, more than a decade of hard knock lessons about applications, apps, and companies have taught me that the only thing you can rely on is plain text representations. If you want any semblance of continuity and history in your data. Doubly-so for the metadata around your data.

A forum foray into end-of-year management summaries (with ledger-cli) had a handful of people asking about my blog setup and its speed. I realized it’s changed significantly from posts three years back (and where I was using Jekyll and Gatsby), so time for an update post.

TLDR

The benefits of this setup are:

• very fast - due to static content and CDN (content delivery network)
• cheap - pennies-a-glass: it costs me ~$1 USD a month even for very large traffic amounts
• discovery - unlike other setups on managed providers like Github Pages etc, it’s SEO-friendly
• easy-to-operate - simple, easy commands to setup and execute deploys
• zero-maintenance - other than Amazon SSL cert updates (now automatic), have not touched it in nearly 3 years now

Despite the fact I was not the biggest Go fan at the time, I tried Hugo . Hugo was blazingly fast to build, has a heap of convenience features I really liked, and a nice ecosystem of plugins, along with some decent themes. Also, it compiles/comes as a single static binary to use. While Jekyll and Gatsby are both nice, both were dead slow to generate (additionally, every node update kept breaking Gatsby or its plugins when I was using it.). Hugo also takes care of your asset pipelining for you which can be a major headache with other static site generators.

Going totally remote WFH over 2021 tweaked choices. I really tried to simplify tooling and focus on process though experimented (particularly between org-mode, notion, and logseq for GTD.).

Flirting with Zettelkasten did not work for me. Spent more time curating notes then action, and wanted a system which defaulted to doing (though some ZK practices made me better at absorbing material and acting on it).

For the interested, you can see the toolchain evolution through 2021 , 2020 , 2019 , 2018 , and 2017 editions of these posts as well if you’re digging for some possibly better ways to do things, especially as we’re in the new year and year two of the pandemic.

Command-line interface (CLI) tools have gone through rapid innovation in the last couple years. Ancient stalwarts have been challenged with better newcomers that make life easier, quicker, and better. I feel this Cambrian explosion of new tools may be because of better CLI creation libraries, but think a certain nod has to go to systems programming languages like Go and Rust becoming more popular.

In the vein of my 2021 Software Tools list , and the CLI LIfe Starter post, I’ve run across a whack of great CLI tools in the last couple months which I incorporated into my workflows, and a notable fistful of five. All are available on both OSX (via homebrew) and Linux.

I experimented a lot with process during pandemic lockdown and with the shift to WFH. Successful experiments had tooling implications. While I do feel tools are less important than your actual process — process trumps all — some tools do make some things you want to emphasize or change easier (or conversely, your existing tools might make it harder).

The big changes in my flow came about from trying to come up with a more web-based, easier sharing and collaborative process than emacs org-mode allowed. I wanted a nicer, more modern writing experience, and abstractions to keep me better organized than a flat file or folder hierarchy. Additionally, I wanted to experiment with implementing a Zettelkasten after reading How to Take Smart Notes which a note-taking-as-thinking organizational system purporting to be conducive to learning, creativity, and content creation, particularly in the academic arena. So, I needed effortless bi-directional linking of concepts, a beautiful writing environment that organized itself but could be modified, and robust task management.

As mentioned in an earlier post , a comment on my emacs plain text workflow versus systems that emphasized collaboration and sharing (ok, really GDocs), and my coinciding annual re-assess sent me down a survey on the important versus the improvable in my GTD flows.

TLDR

After trying all systems in great detail for a few weeks of real-life testing, often side-by-side or duplicating days, I am still wavering between Notion and sticking with org-mode + org-roam (and a few other emacs improvements I picked up in research.). So, I’ll spend January using org-roam and Notion in a real life shootout to make the determination. Right now, I really seem to like writing in Notion, but managing tasks in org-mode, but I have to choose just one, I think. Roam I had to reject due to exceptionally weak and manual task management despite loving its in-context bi-directional linking (which I’m hoping emacs’ org-roam will match). Basically, I wish I could have the baby of all three of the systems since they all have different strengths (and weaknesses).

I’m happy to announce the open source release of harsh today.

Harsh is habit tracking for geeks . A simple, minimalist CLI for tracking and understanding habits. Build great habits. Break bad ones.

Why? Habits, both good and bad, make us. We are what we do habitually. And what we do habitually ends up being what we accomplish .

You can grab harsh most easily via homebrew on OSX or linux with a simple:

Every year, I post on the software tools and workflows I’m using. I always pick up tips from seeing other people’s posts outlining their tools and workflows and it’s helped tweak and improve my toolchain to squeeze out extra productivity. This is what the end of 2019 looked like in tooling.

I’m always mildly surprised when I do this post how much my setup evolves over the course of a year. Sure, there’s innovation in software, and slow changes are often the hardest to see, but as I’m always trying to simplify things GTD-wise changes can be pretty dramatic year to year. For the interested, you can see the 2019 , 2018 , and 2017 editions of these posts as well if you’re digging for some better ways to do things, especially as we’re in the new year (and decade!).

With a little leave time around XMas and a flight back to Canada, I had a bit more time to play around with Rust, and managed to fix an irksome timezone bug that was plaguing habitctl, the minimalist habit tracker CLI.

I’m really enjoying coding in Rust. As a language, I find it makes sense, is performant, and its prescient compiler checking on types and such makes it hard to shoot yourself in the face.