The interview at Zendroid on tuesday went smoothly. I saw some interesting demos and enjoyed talking to the guys. If you're still wondering, the company wants to implement cool robotics-mixed-with-machine-learning stuff that's feasible right now. Needless to say I can't tell much (NDA), but Zendroid is very much the sort of environment I want to work in. Also, they are using extensive unit-testing and git, i.e. doing things properly.

A few hours ago, I got an email telling me I was accepted. I'll be starting some time next month. It'll be interesting to see what working at a startup is like, especially after all the propaganda by Paul Graham and others.

Tangentially, I've recently been making mixtapes and brushing up on my DJ skills. I was also asked to play at a student party next month. Things are progressing very nicely on the music front, and I hope to have a proper mix on-line soon.

Lately I've been studying swedish, working on my candidate's thesis and the software engineering project, working at Zendroid, founding a new student organisation and doing part-time teaching. Despite or because all of this, I've been feeling more upbeat and productive than in ages. Somehow having merely much to do is more stressful than having an abundance of tasks. I guess the diversity of projects is what's keeping me going. Also, the job is turning out to be really interesting and inspiring.

In addition to time-management skills, all this multitasking has been improving my emacs technique. I've resumed using emacsclient and keeping one master session open at all times after a few years pause. Working on a large software project once again offers an opening for all sorts of tools and tricks I'd forgotten.

Working intensively also made me switch back to ion from xmonad. A dynamic window manager just isn't enough when dealing with a plethora of windows. A tag-based one might have worked better, and of course heavily customising xmonad would've probably gotten me something I could use. But in the end ion is what I enjoy using and have many years' experience with; I've no reason to switch.

BTYL, got real stuff to do.

As I mentioned earlier, Zendroid uses git. After I started as the third developer at the startup, we needed to establish real (scalable) development practices. I started looking at different open source issue trackers. Two systems that are implemented as git plugins are ticgit and git-issues, the latter being a python clone of the former ruby program.

Both projects are still in their infancy and quite unpolished, but still managed to seem promising. They track tickets that can be assigned, prioritized, commented and solved. However, they do this by using something akin to git-shelve to store ticket information in a separate branch.

This just doesn't work. Git can only operate on one branch at a time. Pushing and pulling changes to the issues branch require checking it out (involving much copying and losing changes made to the working tree (unless git-stash is used)). Also, a single commit can not both fix a bug and mark it as fixed. Of course one could keep a separate working copy with the issues branch checked, which is again not at the level of integration we would want. The tools could (quite easily) provide an interface for syncing the issue branches but although git-issues has such a thing documented, neither project implements it.

This leads to the other gripe I have with these two pieces of software. Both were inadequately documented and often threw backtraces instead of error messages. Somehow both have gotten stuck at the proof-of-concept stage, possibly because of the cumbersome separate branch model. We started looking at alternatives, briefly considering the all-so-trendy Lighthouse and totally not considering trac.

Ditz to the rescue. I had heard of the project previously but had thought it as something simple like devtodo. Not so. Ditz offers all the features git-issues and ticgit do and more. One can group tickets into bundles (releases) and annotate, comment and query them in all thinkable ways. Additionally the tickets are stored in a separate directory in the same branch as the code they refer to, and are formatted as YAML (yay!), making merging very easy and pleasant. Ditz is also well-documented and actively developed. The only problem we have bumped into is that a ticket that someone has claimed can not be "stolen" without hand-editing the ticket files.

So, that sorts out the technology side. On the human side of things we schedule tasks with dated releases. All the issues grouped into a certain release are meant to be cleared before the set date. In addition we have larger releases that roughly correspond to milestones. Ideally, all work done should be related to a ticket claimed by the developer and marked as "started". Changes to tickets are propagated in sync with code changes.

Update 2008-10-06: Git actually uses hardlinks when changing branches, so performance isn't the problem. In any case the semantic load (and ugliness) remains.

Also: I forgot to mention that we have a separate review project that contains code-review tickets.

Trying to overcome my writer's block by jotting down some random thoughts.

1

My life is a cyberpunk novel. I rise tired after minimal sleep, slam stimulants into my system and run through a DDR-esque concrete ghetto to the tram stop. I only wake up properly at work where I juggle abstractions and try to teach robot hands to pick up cubes in a virtual reality.

2

The Haskell project course is chugging along nicely. People are encountering frustrating and sometimes even interesting real-world problems like FFI, installing libraries and handling exceptions in pure code. I plan to blog on the exception issue soon.

Also, we've been thinking about the future teaching of functional programming at Univ Helsinki. There's a course on formal type theory (with Coq!) coming up this fall.

3

At work we've moved to Roundup, a pretty pleasant issue tracker that is easy to customize. The default templates could be a bit cleaner tho. (E.g., there's support for storing different queries in the db but the menu uses hard-coded GET parameters).

I've been working on compiling our stream computation DSL to jvm bytecode that just loops over a bunch of arrays. It's been sweet so far.

5

Foundations for Programming Languages is a great book. Tackles some type theory but mainly other cool stuff such as algebras (as featured in algebraic datatypes), different models of lambda calculus and logical relations. A good complement for TaPL.

7

Have travelling to do this summer:

• The IMC competition in Bulgaria
• A trip to Austria, including hiking in Hohe Tauern national park and some Vienna
• Cottage and boating trips with parents & grandparents

Random links

for your browsing pleasure

• http://multigrainknackebrod.blogspot.com/ -- a somewhat interesting blog
• http://kdice.com -- nice simple risk-like game
• http://www.lawfulpath.com/ref/sw4qw/index.shtml -- a conspiracy theory
• http://jpatokal.iki.fi/music/mp3/gnosis_at_inkvisitio3.mp3 -- some nice gabber