The Software Scrutiny Journal

My calendar began as a haphazard Google calendar. Not all of my events went in there. In fact, most of my life was just in my head. I also didn’t review my upcoming events all that often. To be fair, I was just in the auto-pilot, senioritis, tunnel-vision-for-graduation phase. If anything, I probably received my calendar events as a push notification ten minutes before. Needless to say, I was not as organized as I had liked.

The Hook

On a sunny morning shortly after beginning my first full-time position, I read a post on Getting Things Done (GTD). Frew taught the power of text files, and how I could use them to organize my life. To this day, I keep a very similar structure as this blog post. A couple of times I’ve deviated away from it out of laziness, but I’ve found that it’s really important to keep the GTD structure. GTD crushes to-do lists, gives reminders of upcoming events and helps maintain a high level of productivity. I sometimes like to think of it as my personal assistant. It sounds kick-ass, but it’s actually a fairly boring process (which is how all to-do lists should be :)). I can write a separate post on this in the future.

Around the time of digging into GTD, I discovered the personal wiki as a way to organize the information. After looking through a few, I ultimately decided on vimwiki since I already love vim. Every day I look forward to opening my vimwiki to see what the day has in store for me. There is such a joy in being able to fly through my vimwiki pages while organizing the information that is most important to me. Little did I know, this simple text file would become a monster of information. It was the blank slate for many different services to write on. The one service that I want to talk about today is fetching calendar events via caldav. But wait, let’s not get ahead of ourselves.

The Beginning

Where was I? Ah yes, the intoxication of the vimwiki. I liked the vimwiki so much that I created my own calendar inside of it. Yes, I had each month with the calendar days listed. So each morning as I planned for my day, I would track down the day of the year, and I would copy the calendar events into the “next actions” part of GTD.

I was also able to generate recurring tasks. I had filenames called daily.wiki, weekly.wiki, monthly.wiki, and annually.wiki. For each of these files, I had a script that I would run. For daily, it was pretty simple: I would cat daily.wiki and pipe to the vimwiki. For the others, I would have to check the current date and grab all matches with grep. This became an issue when I had increasingly complex recurring rules (e.g. repeat an event on the third Monday of each month).

I realized that this couldn’t scale, so I decided to write a program that would interpret a file, and output the list of events for a given date range. I named it “rcal” since it was a calendar program written in rust. The program implementation was a little more difficult than I initially perceived it to be, so I did a little online research. Apparently, there’s this thing called gnu gcal that was made in the mid-90s, and it was exactly what I was trying to recreate! The last version release was in 2017. So while it’s not a booming piece of software, it is definitely a stable one which has stood the test of time.

But as Unix philosophy touts, software is made to be destroyed. Said another way, software should be created in small chunks so that any single chunk is disposable without affecting the others. When it became time for an upgrade, I was able to dispose of gcal without affecting my vimwiki, GTD process, or any other system that I had in place at the time. The main reasons for needing an alternative stemmed from two places:

1. I could not check my calendar on my smartphone. Instead, I always had to tell people “I’ll check my calendar when I get home”. This was less than optimal because I would forget to check my calendar half the time.
2. At my full-time gig, we use Google calendar to coordinate events. Having two calendars in two different places felt a little disjointed – it would be much simpler to look in only one place.

I ended up using a program to pull from Google calendar and pipe the results into my vimwiki. It worked so smoothly that it didn’t just end with my work calendar…

Today

So I continued on my journey, and to my surprise, I returned home in a full-circle fashion. I am now happily using ics files again, but at a lower level than I did before. I use khal as my CLI tool to do all of the heavy lifting CRUD operations of my calendar. Khal then writes these changes to an ics file locally. Once I make changes, I use vdirsyncer to propagate changes to/from the remote.

My morning routine looks a little like this:

1. Grab a cup of coffee
2. Sync the calendar with vdirsyncer
3. Run khal list to fetch today’s events and tasks
4. Pipe results to vimwiki

Steps 2 through 4 are all inside of a bash script, so I don’t actually have to think about running these. Scripting out #1 would be quite the bonus as well. xD

I do not really use the GUI for viewing or editing calendar tasks, and it’s not because I dislike the GUI (even though I kind of do). Since I record all of my deferred to-do items in my calendar, this would get really bloated when viewing on a graphical interface. All I really need is a plain text list of tasks.

As for hosting, I use Fastmail. I debated self-hosting but decided that Fastmail would be a more stable solution.

The most fascinating part of working in a Unix state of mind is that you can experiment without fear. Each piece of the puzzle is truly independent, and you can try many different pieces for a problem. I look forward to seeing how the journey continues to evolve into a more powerful, yet simple system.