For many years, I worked for the same organisation. There are positives and negatives in this sort of corporate longevity. For almost the whole time I was there, my private me was inextricably mixed up with my corporate me. I started at Optimation before there was email. When email came along, I was firstname.lastname@example.org. I didn’t have a personal email address. Eventually I got a Hotmail account; but it wasn’t really me.
At Optimation, I had a Solaris workstation, mostly SPARC, for a short time X86. With Solaris came Calendar Manager. I soon came to depend on it. Other people had personal organisers, or diaries. I used CM. Again my personal and corporate personae were interlinked.
When Optimation and I parted ways, I needed to extract my personal bits. By that time, I had cable Internet at home and a little-used email address. This is now my main email presence.
How would I replace Calendar Manager? I suppose I could have run Solaris X86 at home. These days I could run OpenSolaris in a VM. Back then, I searched around and came across Remind.
Remind is my idea of a Killer App. I cannot sing its praises highly enough. Remind comes from Roaring Penguin and is written by David Skoll.
Why Remind ticks all my boxes
Basically, in my opinion, Remind exemplifies the right way to implement a GUI. In fact, one could argue that there are two Reminds: a command-line version, and a GUI. I suspect that David started by writing the command-line version; he added the GUI front-end, TkRemind, later.
It provides a friendly graphical interface which allows you to view your calendar and add reminders without learning the syntax of Remind. - TKREMIND(1)
But the two are beautifully integrated. The term “front-end” does it an injustice.
Remind has a very rich and powerful language to specify reminders. More commonly used reminders can be created simply. But there is also a bewildering array of features which are more complicated to specify. So, if you want to do the tricky stuff, you can; you’re just going to have to work a bit harder. If you have simple requirements, you can stick to the GUI.
I believe that it is hard to find applications that can be used easily and quickly by beginners, but can still provide all the features for users who are there for the long haul. In this, Remind suits me very well. I am often reluctant to spend a long time learning an application before I can see any results.
With Remind, I was able to see useful and usable results in a matter of minutes. In the last 4 years, I have learnt more about Remind and can do more with it. It’s called ROI (Return On Investment). In this case, my investment is my time. I want to be able to make a small investment and recoup it before making bigger investments. I was comfortable investing the extra time in learning more, because Remind kept giving back. It has never disappointed me. It’s analogous to a satisfying relationship.
A Tour of Remind
TkRemind has a bit of CM about it. Typically, it displays a view of the current month. Click on a day and you can add a reminder. These can be quite complex. I don’t think the details are important. You can find out more at the URL above. You can also go to Remind: The Ultimate Personal Calendar which was the article that turned me on to Remind.
To me, what makes Remind so special is the brilliant (and very simple) integration of Remind, TkRemind and the supporting database. That and it’s near-infinite flexibility; I have found nothing set in concrete.
By default, TkRemind reads $HOME/.reminders. That’s what I started with. Eventually, I decided my requirements were better served another way. Instead of a single file, I now have a REMINDERS directory. In that directory, I have a “main” file (.reminders) and perhaps a dozen include files. The names of these files tell you the story:
.reminders The "main" file .reminders_birthdays .reminders_custom personal customisations (see below) .reminders_daylight_savings .reminders_public_holidays public holidays in my neck of the woods .reminders_utility useful definitions .reminders_year_by_year a container for the following .reminders_ad_hoc_2011 uncategorised reminders .reminders_footy_2011 .reminders_movies_2011 .reminders_theatre_2011 .tkreminders reminders inserted via tkremind (see below)
.reminders_custom needs a little explanation. One of the nice things that come with Remind is a highly sophisticated capability for calculating astronomical events eg sunrise, sunset. However, for this to work, your location (latitude and longitude) are essential. This is the file in which I set these parameters.
I discovered that TkRemind permits the user to have a separate file for entries added through the GUI. I use .tkreminders for this. It’s a little feature that demonstrates why David is brilliant.
At first, I had a single reminder file based on a sample provided with the software. Then I decided I wanted to separate different parts. One of the obvious separations revolves around things that happen in a calendar year. Once the year is over, there’s no point keeping them in the database (archive perhaps).
All these files can be kept under revision control eg RCS. I guess it’s more useful for the first group of files above; these constitute the infrastructure as it were. The group with the year (2011) in the name are only relevant for a single year.
How does it all hang together? In a word, superbly. It’s a classic case of horses for courses. If I want to add a single event, like a dentist appointment, I do that through the GUI. Anything ad hoc but easy to describe can also be added through the GUI.
Each year, when the football fixture comes out, I edit .reminders_footy_YYYY – because I find that sort of entry easier to generate using an editor. The same is true for the other year-by-year activities.
If you think about it, you realise that adding one-off reminders through the GUI makes sense; but deleting them is often best done in bulk. From time to time, I can edit .tkreminders pruning old entries.
The whole thing integrates seamlessly. If I edit the underlying text files, I don’t need to perform any magic to get the changes reflected in the GUI. At worst, I only need to go forward a month and then back to the current month to see the effect of my changes.
Remind does not try to be an operating system:
You can use any text editor capable of creating plain ASCII files ...
It just does the one thing extremely well.
How can you possibly manage change in a GUI-only environment?
Consider Microsoft Word. It has a mode which lets you compare one rev with another. But this could be seen as the bane of Linux purists. An app should do only one task, be as small as feasible and do that one task well.
I already have diff and grep. I don’t want the next app I adopt to provide another flavour for me. For all I know Remind has a search function. I don’t care. I know that all the data is stored in flat text files. Easy to search – grep. Easy to manage revisions – rcs. Easy to determine what’s changed – diff.
And for those things that are best done through a GUI – TkRemind: quick, clean, easy to learn, easy to use. Dare I say intuitive?
If you already have something which handles your calendar needs, I doubt that this article will get you to change. That’s fine. To each his own.
On the other hand, if you’re dissatisfied with what you have, or you’re looking around, Remind has my unequivocal recommendation.
While I was writing this article, I was struck by the possibility of improving the way I handle the year-by-year events. I now have several files which achieve the equivalent of a couple of loops:
# for year in lastyear thisyear nextyear; do # for activity in theatre_ footy_ movies_ ad_hoc_; do
The nub of the loop is to conditionally include only those files which exist.
It means that I can now add or delete files of the form
without ever changing the infrastructure. If the file exists, it will be included; if not, not. In December, I can look ahead to see what’s coming up next year. In January, I can see what I did the previous year.
Try that with your favourite GUI.