I’ve been looking for a good software to help with writing a journal/diary. Although I didn’t know exactly what i had in mind, there was a couple of features I thought I needed (and which I has discovered I needed as I tried out the different software packages that exists).

1. Ease of start writing. I don’t want to jump through hoops to just start the writing process.
2. Browsable/searchable. I need to be able to easily go back to previous entry, or at least be able to search for them.
3. Preferably text file format. In case the program stop working or I want to upgrade/change program, I rather the files that are created are in a common format. Making it hard to move away from a program means that developer don’t have faith that people will stay program voluntarily (yes, I know there are some efficiency reasons for going binary).
4. Simple. KISS principle

Wikis are interesting. They pretty much cover 1,2 and 3. The problem is, I don’t want to install a webserver on my home system just to be able to write to my journal. Also, the browser isn’t the best editor in the world. I do have WordPress installed on my public webserver, so I could in theory create a private section. But again, I don’t think a browser is the best editor.

Kontact’s Journal
Journal that comes with Kontact is pretty basic. Since I already use Kontact as my primary mail client, it wasn’t that much that difficult to use Journal.
The problem is that Journal is too basic. Once you write an entry, there is no way to find it again. There are no indication in the Calendar whether a given day has a journal attached to it. So you have to pretty much go to each day and check whether the journal entry you want is there or not. There is a very rudimentary search, but sometimes you want to just browse.

Now, Emacs being the all-in-one editor probably had something I could use.

journal-mode had everything I really needed. Problem was that it wasn’t maintained anymore. No support for Emacs 22 and beyond, which is a problem.
planner-mode forced too much structure. Programs should conform to me, not the other way around.
muse-mode made it easy to start writing. But it has the problem of structure. I wanted to be able to browse my journal by period and tags. I could set it up manually, but really… the program should take care of it.

org-mode. The perfect module, so far. It fills all four of my needs. It took my less than an hour to wrap my head around it to use. Org-mode also seems to be extendible enough for me to use in other parts of my life (like a day planner), which means that I can become more productive the more time I spend on it. So far, after 24 hours of use, I consider it a keeper.

Note: Sasha Chua has an blog entry about the topic. She also has lots of articles about using Emacs to its fullest potential.

Coding – home vs work

One thing many of my non-developer friends ask me is why I would code at home when I do the same for work. For me, there is a world of difference between coding at home and coding at work.

Coding at work means that you are basically stuck with the technology and project that management decided. If you are lucky, you might be part of a project from the beginning and can influence some of the decisions. Still, once decided, there are probably not enough time to make changes later (as much as the agile paradigm promises otherwise).

Working at home means you set the speed. If you do something you are unhappy with, whether it works or not, you can always change it. Since you are basically the management team, you can choose the technology and tools. I also feel like I learn more coding at home, since there is more time for experimentation.

One thing that you need to be conscious of when coding without deadline is limiting the scope. It’s much easier to never be happy with the work, and therefore never finish. One of my favourite windows managers, Enlightenment, seems to be a example of this (DR17 has been in development since 2000).

Still, tinkering at home keeps me interested in coding, so that’s why I do it…


I forgot my password.

I had this brilliant idea of protecting the documents on my laptop with encryption some time ago in-case it ever gets stolen. And of course, encryption is useless without a good password. And now I forgot the password. And the backup doesn’t cover the latest stuff…

At least I decided to cut down on the number of unique password I have to remember. If only I could figure out what the password was for this particular set…

Amending the checkin

After finishing a particular software feature, I like to check in my work. The problem is, I get into a dilemma. Do I check in now, or wait until I’m sure the feature works as advertised. If I check in now, then I might discover that forgot to add something else to the checkin. If I don’t check in now, I might start on another feature, and then it gets messed up.

git has a wonderful feature that fixes this. git commit –amend. Basically, you commit your changes. Later on, you realize there were some other files that should have been committed alongside the first commit. So you just amend the previous commit with your new files. Really nice feature, and should make the history logs much nicer to look at.


I’ve been playing with KDE4 for awhile now since Kubuntu released 8.04. Although it’s a little more polished and useable than when I tested the 4.0 release, it’s still not quite there yet. That is, it doesn’t give compelling reason to switch from KDE 3. That said, KDE4 is beautiful.

One of the complains against KDE that it wasn’t very beautiful. It was very functional, but beauty… To me, it was like most enterprise level software. Functional, does what you need it to do, but it’s not a thing of beauty (if you want beauty, check out what Apple is doing with their stuff). KDE4 is beautiful. The artwork team in KDE has done a really good job. And with the addition of 3D accelerated graphics, it actually feel smoother too.

I really look forward to what the KDE team has in store for v4.1 and beyond. It’s going to be an exciting year.

cross-platform development

One of the problems of doing cross-platform development, is that you don’t necessary know what the environment will be at the person who is compiling your software. So, you need to be able to check this and maybe notify the user what additional software needs to be installed. You also want your build system to be flexible enough to maybe work around issues and options.

I used to write the build system for the unix development at my previous work. Since the target was limited to HP-UX and Solaris, it was somewhat easy to just create a script which figured out which platform we were at, and then copy the platform specific Makefile to the right location. When I started working on my own private projects, I wanted to make it more robust. Initially I was looking at the automake/autoconf systems. I found it a little too complicated for my needs, although autoconf by itself might have been useful. I still find it somewhat troubling to have to learn another language (M4) to write the configuration files. To me, configuration files that generate the Makefiles should be as simple as possible.

While I was investigating and trying out build systems, I heard that KDE had started using cmake. This made me at least a little curious about it.

The initial impression was that cmake makes it really easy to get started. I was up and running faster with cmake than I did with the autotools chaintools, and almost as fast as writing my own Makefiles. Now, my projects aren’t as big as the KDE project, but if it works for them, it should work for me.

One of the problem I found is the some problem I have found with most cross-platform tools: it has to target the least common denominator. Some of the features seem to indicate that cmake was first developed on Windows, or that developers were primary Windows developers. For instance, there wasn’t a good way to clean up custom generated files using cmake, as in you could make clean target in Make have a dependency on something else, so that that something else also got removed when clean was called. Reading the faq, this seems to have been fixed in 2.4.

Although I haven’t done anything complicated with cmake yet, so far I have been pretty happy with it. It isn’t much more complicated than handwritten Makefiles, and it should save me tons of work on porting.

Kubuntu 8.04 (Hardy Heron)

I’ve decided to reinstall my Linux system, and in the process upgrade to the next Kubuntu version, 8.04, also known as Hardy Heron. I usually don’t like to reinstall my OS when I upgrade to a new version. One of the reason I decided to move to a Debian distribution was that I didn’t have to reinstall during upgrade. Unfortunately, when I initially installed Kubuntu 6.06 (Dapper), I made the / partition too small. Although it was big enough for normal usage, during upgrades, with multiple versions of the kernel, firmwares and kernel modules, it got too tight. Hopefully, the current size of 1 Gb should be enough.

In general, I hate reinstalling an OS. Mostly because I spend some time customizing it, writing scripts to help me in the day-to-day work. Most of the time, I forget to backup these scripts, so I have to recreate them once I notice they are missing. Mostly finding everything to make the desktop look and feel exactly as I had it before I made the upgrade do take time. Of course, I’m also finding functionality that I’ve never noticed because they have been hidden because of customization, or I just hadn’t looked.

Although I stopped installing beta software (unless force to it), I’ve been pleasantly surprised by the stability of Hardy. Stuff like hibernation and suspension that I previously had problems with, works now. I never got the kernel in Gutsy to boot, so I had to be content with the kernel from Edgy, but 2.6.24 works perfectly now. And Kontact seem more stable than previous versions. The addressbook has gotten a much needed speedboost (when using LDAP), although it still doesn’t expose all the fields. This version seems to be a keeper.

Distributed Version Control Systems

I recently moved all my development over to a distributed version control system (dvcs) called git. I’m not going to write about dvcs and the difference/advantage/disadvantage between it and central version control systems, like Subversion. There several good articles and blogs on that topic around already [1][2][3]. This is more about my journey.

I started my (development) career using SCCS and RCS slowly moving towards CVS. They worked, with some warts. Some of the weaknesses are well-known, but for tracking individual files, they work really well, and I still use it. Once Subversion came on the scene and stabilized (with the introduction of fsfs repository type), I was hooked. One of the thing I really liked was the concept of change set, that is set of changes that logically belongs together. Like say, a header file and the source file. Change the header file and the source file needs to be changed too.

I recently got in trouble with my svn repository when my working set got into an invalid state as far as my repository was concerned. What happened was, when I moved back to Norway, I shipped my computers. I had made a backup, but had continued developing. And the shipping had taken time, so I had created a new repository from my backup. But since my working set was at a different version than my backup repository, svn wouldn’t let me checkin. Frustrated, I started looking at other vcs.

What got me first looking at git was the google talk by Linus Torvalds. I then read up at the current state of dvcs before I started testing out git, and I was hooked.

What I find interesting is that git feels ‘natural’. The impact on my development process is minimal. As an example, to create a tag in svn:

svn copy svn+ssh://server/path/to/project/trunk svn+ssh://server/path/to/project/tag/{version}

The same command in git:

git tag {version}

Branching is similarly easy in git. But I think the main advantage is that I now can I have multiple repositories for the same project.

My current work process is like this:
edit edit edit
checkin into local repository
edit edit edit
checkin into local repository
happy state
push to private server
edit edit …
once stable state
push to public repository

At at any time during the editing phase, if I’m unhappy with the track I’m on, I can always throw out the changes without messing up my private or public repository.

I really think you should at least take another look at the dvcs and see if it’s something for you.

[1] Wincent Colaiuta’s development blog
[2] Dave Dribin’s Choosing a Distributed Version Control System
[3] Ben Collins-Sussman’s The Risks of Distributed Version Control

mail labeling

Following the previous post, I’ve been playing around with labeling my email. Mutt has really good labeling support, mostly because of its flexibility. With it, I can pretty much do anything I need using labels (add, delete, modify, limit views to a given label etc), so it has become my primary email client these days.

I used to use Kontact, and I still like some of its functionality (like setting up search folders), but not being able to edit and add labels make it hard to use. It’s also not that stable when you’re using imap. Looking forward to trying it out again when KDE 4 turns stable. Hopefully, it is more stable there.

Being, the lazy bum that I am, I really don’t want to manually add labels to email from people I know when the computer can do as good a job as I can. Enter maildrop. One thing that I noticed was when I wanted to the system to add multiple labels to a given email because multiple people was on the mail list. I therefore wrote the following maildrop rule (procmail users can probably write a similar rule for their system):

# Get address from the From, To, and Cc line
foreach /^(From|To|Cc): .*/
    foreach (getaddr $MATCH) =~ /.+/
        # check if the address is in the label file
        # label file has a key/value pairing looking like this
        # exlabel
        # where first part is the address and second part is the label
        TMPLABEL=`grep $ADDR labels`
        if ( $RETURNCODE == 0 )
            # if message already has a label, keep it
            LABEL = `echo $TMPLABEL | cut -d' ' -f2`
            if ( /^X-Label: (.*)/ )
                xfilter "/usr/bin/reformail -I 'X-Label: $MATCHLABEL, $LABEL'"
                xfilter "/usr/bin/reformail -I 'X-Label: $LABEL'"

So far, it’s been working really well.

Organizing Your Email

One of the problems of organizing your email is how to do it. I don’t really like deleting old email. Mostly because I like to go back and read some of the older email. One problem with that is since the outgoing email (from me) got stored in the Sent folder, I didn’t do a really good job at storing those email. So the threads and context are often broken, especially if people didn’t quote the whole email (and people who used email back before 2000 did a much better job at trimming quotes). Another problem was, how do I file it the email? I used to file everything job related into a job, anything academic into school, anything from friends into letters. Of course, then I start getting email from coworkers not job related. Do they go into jobs or friends? Same with fellow students…

Last summer I read two brilliant (related) posts on email handling: one from Scott Yang and the other one from Aristotle Pagaltzis. Basically, stop filing your email. Just archive everything (similar to the Gmail model). Don’t worry about categorizing. Trust your email client (or search functions) to retrieve your email.

I’ve been using this scheme since last summer, and so far, it has worked brilliantly. I keep all my email conversations in my inbox until the conversation is finished. Then I archive it, without thinking about where to file a specific thread. Mailing lists are special in that they go automatically into their own folders, but then again I don’t really subscribe to many mailing lists anymore (mostly security related). Otherwise, I just get them through the gmane service. One thing I did modify was that I set up my system to automatically archive the archive by year. So that December 31 at 23:59 (or so), everything in archive gets moved to archive.YEAR.

I do miss some of the features that Google introduced with gmail, though. The labeling facility is gmail is pretty brilliant. So, you can manually give an email a given label, and you can then search on that label. I miss that functionality. You can use search folders (in kmail, that I use and probably other email clients), but it’s not the same. One problem is that some people change their email, and then you need to update the search parameter. It would be much easier if you could just click on a button that said tag this as that. One problem would be that the tag wouldn’t work across email client unless there was a unified way for email client to read the tags, say x-tag or x-label. Of course, this mean that the email itself would have to be modified by the client, although some clients already do this.

In any case, currently the new email handling scheme works fine, and certainly makes me more efficient.