Navarra’s new digs

After a few month hiatus of working from home and on site for various clients, I’m happy to report that Navarra has a new office on 2020 University, sharing space with Syntenic, DokDok, and a few other local Montréal companies. It’s a small but cosy little space with a spectacular view of the city 20-odd stories up. Feel free to ping us if you’re in the area and want a tour.

Making iPhone apps universal

Just a quick note to point out Noel Llopis’s excellent post on how to turn an existing iPhone app into a universal app that runs on an iPad, without having to suffer with pixel-doubled jaggies. It turns out there are a few surprises, so it’s handy to have a guide.


Having had trouble with all the Mac OS X Dashboard widgets for time tracking with 37signals’ Basecamp project management tools, I’ve written a new one called Basewatch. It’s simple, robust and open-source; any feedback is welcome.

Give it a spin at

The definitive iPhone MapKit polyline example project

Polylines in MapKitPolylines in MapKit. Seems like such an obvious thing to have, yet completely not provided for in Apple’s default SDK. Why? Who knows; perhaps they don’t want to encourage people to write applications which violate Google Map’s terms of use (which forbids writing applications which provide real time navigation services).

That certainly hasn’t stopped people from trying to build their own homebrew polyline classes to plug into MapKit. In particular, Craig Spitzkoff wrote up a document describing a method of displaying a polyline on the map using an annotation, albeit not updated in real time (the polyline would disappear when the user is performing a zoom action on the map). Nicolas Neubauer later expanded upon Craig’s idea with the idea of hooking into the annotation view’s center property (called by the map kit view) to get notification to resize the polyline appropriately on zoom and move events. Unfortunately his description has a few errors (you need to hook into MKAnnotationView, not MKAnnotation), but the general idea was correct and was a rather elegant hack around the limitations of MapKit.

In any event, it so happened that I needed something to display a polyline for the Transit to Go project and was a bit perplexed about how to go about it. To resolve the confusion around how to do this properly once and for all, I decided to code up a quick sample implementation of a zoomable, transparent polyline on a MapKit map. The implementation is extremely bare bones and unoptimized but gets the tricky bits out of the way so you can concentrate on modifying it and improving it for your application’s needs. I decided that creating a general framework around this idea was kind of overkill, so decided to leave it to people to copy the relevant source files into their applications. I’ve placed the work under an extremely liberal license in the hopes that it will spread far and wide. Just remember to respect Google Map’s terms of use(read: no real-time navigation) in your app.

Go ahead and checkout the repository on github. You know you want to.

On working around mechanical failures with software

Running a business involves reams of paperwork. Reams of paperwork eventually means miscategorized, misplaced, and mishandled documents. The (partial) solution: a scanner, of course. I say partial because it’s still easy to have all your digital files in complete disarray, but at least archiving and searching is a fair bit easier.

Of course really good scanners are not exactly cheap. We bought a Scanjet 5590, which, for the price, is pretty decent. Most importantly it has a document feeder, crucial if you’re scanning long, or many, documents.

Now I encourage the use of both sides of paper, but it is a mechanical nightmare to scan double-sided paper correctly. Sadly the 5590, while officially supporting this feature, is not of sufficient quality to make this really useful–I’d say it jams about 50% of the time.

I’m used to using software to work around hardware bugs. Back in my last year of university, we discovered that the DSP we were using for our big project had a bug in its serial port: after a few kB, the serial port would lock up and refuse to handle any more data until it was reset. After asking the manufacturer about this problem, they verified that it was indeed a bug and would be fixed in the next revision–not too useful when your deadline is in a couple months. We ended up writing a simple lock-step protocol, with the firmware resetting the serial port if it hadn’t received expected data after a short period of time.

But back to scanners. I wasn’t prepared to shell out the many thousands of dollars required for professional scanning/photocopying/window-cleaning equipment. Luckily, there is a wonderful little utility called pdftk, the PDF toolkit. It’s available for Linux, Windows (at least via Cygwin), and probably a bunch of other systems. It can split PDFs into separate files for each page as well as concatenate PDFs, perfect for what I was doing. (It can also do a whole pile of other things, less important for me at the moment.) So the solution is to scan one side of all the pages through the feeder into one file, scan all the other sides into a separate file, and use a series of pdftk commands to split and then merge the files into a single PDF with all the pages in the correct order.

I wouldn’t be much of a programmer if I was content to repeat those commands every time I needed to scan a double-sided document, so I spent a little bit of time and wrote a short Python program to do it all for me. I present it below the cut. It should work in Linux as well as in Windows.

#!/usr/bin/env python

import os, os.path, subprocess, sys, tempfile

def usage(prog):
  print '%s <right-side PDF> <left-side PDF> <output PDF>' \
        % prog

def cleanup(tmpdir):
  os.system('rm -rf %s' % tmpdir)

if len(sys.argv) < 4:

rightfile = sys.argv[1]
leftfile = sys.argv[2]
outputfile = sys.argv[3]
tmpdir = tempfile.mkdtemp()
rightdir = os.path.join(tmpdir, 'right')
leftdir = os.path.join(tmpdir, 'left')

os.system('cp %s %s' % (rightfile, rightdir))
os.system('cp %s %s' % (leftfile, leftdir))

for i in ((rightfile, rightdir), (leftfile, leftdir)):
  p = subprocess.Popen(['pdftk', i[0], 'burst'], cwd=i[1])
  rc = p.wait()
  if rc != 0:
    print 'Failed to burst %s.' % i[0]

rfcount = 0
for f in os.listdir(rightdir):
  if f[:3] == 'pg_': rfcount += 1
lfcount = 0
for f in os.listdir(leftdir):
  if f[:3] == 'pg_': lfcount += 1

if not (0 <= (rfcount - lfcount) <= 1):
  print 'The number of right-side pages (%d) ' % rfcount + \
        'is not equal to or one greater than the'
  print 'number of left-side pages (%d).' % lfcount

command = ['pdftk']
for i in range(1, rfcount+1):
  rpage = os.path.join(rightdir, 'pg_%04d.pdf' % i)
  lpage = os.path.join(leftdir, 'pg_%04d.pdf' % i)
  if os.path.exists(lpage):

command.extend(['cat', 'output', outputfile])

p = subprocess.Popen(command)
rc = p.wait()
if rc != 0:
  print 'Failed to concatenate pages.'


Remote logging with Apache 2

Just a quick note, since this didn’t immediately come up in a Google search.

Say you have yourself an Apache 2 server on Unix (naturally), but you’d like the logs to end up on a remote machine, for any number of reasons (security, backup, just plain having all your logs in one place, what have you). So you set up rsyslogd on your log machine, set up syslog on your web servers to point to it… and you get nothing from Apache. Apache doesn’t go through syslog by default, writing its own log files instead.

The solution for Apache’s error logs is obvious enough: just add “ErrorLog syslog” to your config file. But mysteriously, there’s no analogous directive for the access logs. The solution is still straightforward enough, and it looks like:

CustomLog "|/usr/bin/logger -p -t apache2" common

I suppose this shouldn’t seem shocking, but when we were looking this up, many people seemed to forget that (a) the “logger” program exists already, and (b) you can pass options to it directly from the Apache config file, without an intermediate script. In other words, there’s no need at all to be writing additional scripts, which you might not have known based on the Google results I was getting earlier.

Protocol https not supported or disabled in libcurl

This is the second time I had to figure this out, so I’m documenting it for prosperity. It’s certainly nothing special, but I’m sure that others have wasted time searching for the solution as well. Assuming you’re using Macports, read on.

I’ve been automating a bunch of stuff with various rake tasks in a Rails project. One task in particular, has a line similar to the following:

curl --user > db.sql

Which, when run, yields the following error:

curl: (1) Protocol https not supported or disabled in libcurl

To fix it, do the following:

sudo port deactivate curl
sudo port install curl +ssl

And voila.

“git grep”, another grep alternative

So as I was recently saying, ack is a fine grep alternative for programming tasks, but I should also mention another useful tool: git grep. It’s extremely simple, it just searches through all your checked-in files for the given expression. The advantages are that it’s extremely fast due to git’s efficient disk layout, and it’s reasonably common to want to know where a given string has been checked in (especially if you have a lot of generated source code). The drawbacks are that its command line options are a bit limited, it’s missing all of ack’s nice features, and of course it only works on git repositories. Still, a handy little tool to have at hand.

ack: grep for programmers

If you find yourself using grep a lot to search through code files, you should probably take a look at ack (packaged as ack-grep in Debian and Ubuntu). It’s like grep, but optimized for searching through codebases, particularly ones that involve multiple languages.

As an example, say you have a project that involves a mix of C++ and Python files, and you want to find all the occurrences of “foo” in just the Python files (this happens to me all the time these days). With grep, you have to say find . -name \*.py | xargs grep "foo", or thereabouts, whereas with ack it’s just ack "foo" --python. For languages with multiple possible extensions (e.g. Perl, C++), this is even nicer.

OK, maybe you’ve already set up all the grep aliases you could ever want, so never type those ugly command lines any more. Even so, I still love ack, because the search results are that much more readable: the filename only shows up once per file, with each match within the file having only the line number taking up space, like so:

$ ack Hello
3:// Prints "Hello, world!"
6:    printf("Hello, world!");

I find this makes the results significantly more readable. And what I haven’t tried to replicate above is how it highlights both matches and the filename with a bit of colour, making it even easier to scan.

And on top of all that, “ack” ignores your editor’s swap files by default, and is 25% less typing than “grep”! So give it a spin, I started liking it right away.