schain My Heart

Posted on Feb 27, 2021

Good news! Earlier this morning, in case you didn’t notice, I released the very first stable version of my little project schain! Hooray! Let’s celebrate its coming of age! \o/

schain is a habit tracker which draws inspiration from the so-called Stoic Chain. This comes from Epictetus’s advise that if you wish to raise a habit, you should count the consecutive days you follow it through (Discourses, 2.18). In my humble experience, it’s a method that has worked for me multiple times.

But I’m not here to talk about life! Today I want to talk about some BTS stuff that I feel is interesting and fun to discuss in the open.

schain is a very basic program. Its core functionality is that it reads a TSV file where it finds a date and an integer. The date is the last check-in date and the integer is the count of days. Everything else revolves around that concept: schain modifies the file accordingly if you check in via the appropriate command line flag or it just reads the contents of the file. Everything else (e.g. checking that the date you pass schain using -w is a valid date) is just nice perks that make the tool less annoying… more user-friendly, perhaps? Am I talking UX/UI about a terminal program???

In fact, it’s so simple that many times during the initial phases of development I wondered whether schain would make more sense if I wrote it as a Python1 POSIX shell script. Probably. However I must say I’ve only recently learned POSIX shell scripting to a degree in which I feel more-or-less comfortable with it. If I had to start writing schain from scratch, I’d probably have my serious doubts; back then, though, when I started the project, C was the safe shot in my case.

I do have a preference for C for programs that are meant to be tools in themselves. I see shell scripts as “gluing together” preexisting tools. I know probably all my projects in C could be easily translated into shell scripts. It’s more about how I conceptualize a given project. schain in my mind feels2 more as a tool that lives on its own. So, C it was.

One of the hardest things to take a decision about was which date to store in the file. The easy route was to just call time(NULL)3 when the user checked in and there you have it. Problem? I found myself checking into some of my trackers the next day! I’m a busy girl, you know? I never forget to check into my trackers, but some of them are about things I do at night. I usually check into those past midnight, so the date they showed was… one day off. (In the earliest days, the filesystem access time was supposed to act as the check-in date… I’m sure you can imagine quite a couple of ways why that was SO wrong!)

Of course, just calling time(NULL) and have your OS deal with DST, timezones, etc., when converting UNIX and calendar time back and forth is… convenient… But it was impractical. After weeks of meditating on it (and feeling a tad frustrated by a “simple” project), I went for saving a literal date in YYYY-MM-DD format and let the user set a custom date when checking in, with -w (for when).

Isn’t it funny how coding is in many times a matter of weighing options and trade-offs?

Another problem I ran into was whether to store a “description” or some kind of arbitrary text defined by the user. The first versions of schain did so and, in my own usage, was kinda useless… The filename of each tracker does the trick for me: every tracker has a descriptive name that tells me what it is for. Seems reasonable to me that way… and I don’t have to deal with an additional string buffer in the code that way!

I hope this post has whetted your appetite at least for checking out the project’s code! I’ve found it a very fun project to work in, really! And oh, if you find any bugs or you have any ideas you’d like to share, hit up the dedicated mailing list with a message or a patch: ~arivigo/ I’d love to hear from all of you out there! :D

  1. NOPE. ↩︎

  2. Programming is a science, but it’s also an art. Art is about intuition and feeling. I will write on this in the future, but to me programming has a subjective component that simply cannot be neglected. ↩︎

  3. time(2) ↩︎