Earlier today, whilst reading Omni Group’s Mac OS X dev list, I saw someone remark that they didn’t like the fact that Subversion doesn’t preserve Finder labels.

Helpfully, of course, Subversion allows you to set arbitrary, versioned, properties on your files, so it’s actually pretty easy to store the Finder labels and retrieve them when you want them. Or it would be if there were any command line tools that could read and write them.

Well there are now (download the source code).

Once you have that installed, it’s just a matter of doing

svn-save-labels

to save your Finder labels as Subversion properties (a change that you can then commit to your repository), or

svn-restore-labels

to restore them after an update.

Or you can do

getlabel myfile.txt

to see the colour of a label, or

setlabel myfile.txt red

to change its colour to red.

The getlabel and setlabel programs are provided with man pages. The Subversion scripts are not, but they should be self-explanatory anyway.

Well, after spending a very pleasant ten days in San Francisco, I’m back in the U.K., jet-lag and all. Seriously, I’m still feeling pretty tired, and I got back on Wednesday (by the time I made it home, it was late afternoon and I’d been travelling for over 33 hours and awake for a good nine hours before that). Eight hours’ time difference is a real killer when flying East; wandering round earlier today, I felt like a character from Night of the Living Dead :–) Well, apart from the eating other people part, anyway.

Predictably, it has been raining here. Actually it seems to have been raining rather a lot, with the result that there has been flooding in one or two places (not here on the south coast, thankfully). The temperature isn’t too bad though, so at least I don’t feel cold as well as tired.

Oh, I should add that, if you’re ever thinking of going to San Francisco, Hotel Monaco is a great place to stay. It’s much better than the usual chain hotels—they really made me feel at home and it was particularly pleasant having a living room area where you can meet and talk to other hotel guests.

Earlier this evening, I attended the CocoaHeads presentation in the San Francisco Apple Store, which was hosted by Scott Stevenson and included segments from Wil Shipley, Daniel Jalkut and Gus Mueller, as well as a Q&A session which also included Brent Simmons.

So, aside from complementing Scott and the CocoaHeads people on having organised the event, and the speakers for their interesting remarks (and especially the highly charismatic Wil Shipley), I wanted to make a few points of my own. In retrospect I wish I had talked to Scott beforehand by e-mail, because I think it might have been interesting to hear my perspective as a European indie Mac developer (I guess I must be indie, since my company only has three employees, one of them me, and most of what they were talking about seemed familiar), and also as a developer crazy enough to choose a high-support, high-maintenance (and high risk) sector like disk utility apps.

I’ll divide things up by topic, as there were a few things that I think might have been worth saying (and one thing that I did say, but that I think I can elaborate on a bit).

How I started out as an indie developer

Well I think it happened more like Brent Simmons’ description than the other guys, by which I mean that I saw what I thought was a gap in the market and resolved to plug it. I was fairly sure there would be enough money in it to support me, though like Brent I had quite a bit stashed away for a rainy day.

Because I chose something difficult to do, I found that I wasn’t able to make enough headway while working for someone else, so I decided to quit my job to develop our first application, iPartition. For what it’s worth, I don’t recommend this approach, though it seems to have worked out OK for me. I think I’d agree with what the guys being interviewed had to say about picking something simple to start with. There’s an awful lot of code in iPartition (in the current versions, a lot of that is thanks to my friend and colleague Chris Suter, but even in the original release there was a lot of complicated code) and sometimes during the year or so it took me to write the application initially, all of which was unpaid, it was a hard slog. (Worse, some of our customers see the simple UI and think that the app must be simple underneath too; we even had one guy tell us that it was implemented using Disk Utility, which just isn’t true.)

Of course, me being me, I’m probably not taking my own advice here, as what I’m doing next also consists of a number of difficult problems. But hey, I like a challenge, and when it’s finished it will be really cool.

(BTW, if you heard Daniel Jalkut’s remarks about the temptations of writing “we” and trying to seem a bit bigger than we really are, we do do that, but it’s deliberate—we think people are more likely to buy a disk utility from a company they don’t know than from an individual they don’t know. There are obviously downsides to doing this.)

How are things different in Europe?

Well, for one thing, the law is different (in fact, in typical European style, it is different in every member state in many respects). So, for instance, in the U.K., we don’t need a business licence, but we do have to worry about VAT and about the Data Protection Act, and (if you start a company, like I did) you’ll find that company law is different over here.

Some things are basically the same though. You need to keep track of your income and expenditure, you need to pay your taxes, and you need to file the right returns with the right government agencies at the right times. The consequences of not getting this right can be serious (in the worst case, you can land yourself in jail), so either take professional advice or make certain you know what you’re doing.

One big difference though is that doing this kind of (frankly crazy) thing is relatively unusual in Europe by comparison to the U.S.. So you can expect your bank manager to be a bit confused and not really to understand until you explain things carefully. Likewise, many things, the legal system included, just aren’t set up to deal with indie developers. It’s often assumed (for example) that if you’re trading overseas, you must be a huge corporation. This was always true in the past, but the Internet has really changed that and unfortunately many things have yet to catch up with this reality. I remember finding it tricky to obtain business insurance (a legal requirement in the U.K.; if you’re in the United Kingdom, you might try Icon, who I found myself after a number of very silly suggestions from our bank). Also, you’re likely to find that whilst your bank has products that sound helpful, if you ask about them you’ll discover that you’re too small for them to sell those to you, so be ready for that.

Another thing to remember is that, if you’re writing Mac applications, the United States will be your biggest market. That’s convenient for people based in the U.S., but if you aren’t, then you need to realise up front that you are going to be doing a lot of trade outside of your own country, and a lot of that will be in a different currency to the one you use, so you’re going to be exposed to currency fluctuations. There are ways to limit that exposure, for instance by billing in different currencies, but that can cause you other problems.

One other consequence of the fact that indie development is much more common in the United States, together with the tighter regulations imposed by the European Union and inconveniences such as VAT, is that you can’t really use many of the useful services offered by U.S. companies like eSellerate or Kagi. Well, you can, but it will cost you quite a bit, especially if you’re just starting out, because (for instance) they charge large fixed fees for wiring money to your accounts. I think there may be some European equivalents that will be cheaper, though when I started Coriolis Systems, the only one I knew of had just shut down because its operator was having trouble with his local VAT administration.

You will also have problems doing business through one or two U.S. companies who choose not to comply with the European Union regulations on VAT. Let me give an example by way of explanation. MacUpdate run an offer every so often where you get a discount off a particular Mac application, and to do this, they handle the payments themselves, take some off the top and then send the rest on to the developers. This is great for U.S. developers, but if you’re in the European Union, then because MacUpdate doesn’t charge VAT, you will be breaking the law if you let them sell your application. (For those that are interested, it’s the rules on “triangular trading” that you will be falling foul of; these are designed to prevent situations where you avoid paying VAT by selling to European customers via a third party outside the E.U.)

You’ll also find that employment laws are typically more onerous in E.U. member states. The U.K. isn’t too bad, as it happens, but France in particular is notorious for this kind of problem. If you’re in France, and want to go indie, you should probably consider moving to some other member state.

My guess is that the Republic of Ireland is possibly the best place to be in the E.U. right now from a tax and regulation standpoint (though to give another hint for U.K.-based people, if you start a limited company and pay yourself primarily through share dividends, you’ll find that you pay a lot less tax on your income; your accountant should explain all this to you).

Support

You need to keep track of your support. If there’s one thing that drives customers potty, it’s when they have to ask you for the fourth time if you’re actually ever going to do anything about that support query that they sent in last month.

Don’t try to do support via Mail.app. It will work for very small support loads, but guess what? As your app sells, you’ll have more and more customers, and just one bug could cause a substantial proportion of them to send you e-mail all at once. Plus, inevitably, particularly for a more complex application like the ones we write, you’re likely to have one or two customers with ongoing support issues that take time to solve.

Anyway, after a few particularly unpleasant moments where bugs in the early versions of iPartition resulted in more than one hundred support e-mails in a single day (with replies to replies coming in at a pretty steady rate, the result being that the support queue didn’t really shrink significantly for nearly three days), and one or two incidents where a support query ended up being dropped on the floor, I learned the hard way that you need a ticket system.

We use OTRS. It isn’t perfect, and in particular its handling of MIME flowed messages (which are sometimes sent by Apple Mail) sucks. I’ve been meaning to do something about that for a while now, but I haven’t been able to find the time.

Make sure your support system sends replies to people to let them know that you’ve received their e-mails. That will greatly cut down on the number of “did you get this” questions, and also gives you an excellent opportunity to point your customers at an FAQ or similar resources while still allowing you to know that they needed help.

Oh yes, and in case you’re wondering, I don’t recommend that you choose a disk utility for your application. Put another way, even if you have no bugs at all, disk utility software is going to create all sorts of headaches for you, especially in terms of the amount of support required.

Distribution

My take on this is pretty simple. The number of people with fast ’Net access is growing rapidly, particularly in the main markets for Mac applications. Distributors (and “resellers”, if you let them) will rapidly eat into the amount of money that you get paid when someone buys your application, and often there is no real advantage to be had from using them. Generally I think it’s best to offer downloads and sell direct to customers.

As I said at the CocoaHeads session, and as Wil Shipley mentioned in response, they can be useful in some situations, particularly if they are providing a whole range of services rather than just boxing and distributing your app. The company we use in Japan, NetJapan, do localisation, testing, Japanese support (including technical support), advertising (Japanese customers may have seen our ads on the covers of various Mac magazines in Japan), boxing, shipping, dealing with retailers, etcetera. Of course, they don’t do this for free, but without them we probably wouldn’t be able to address the Japanese market and, as Wil said about Act2, we don’t really have to do that much in order to get a monthly payment from them.

One interesting problem that we have with our apps is that because we need to let customers have some sort of bootable CD, our web server is a fairly high-traffic business for such a small operation. I don’t have the exact figures to hand, but we burn through getting on for half a terabyte(!) of bandwidth a month at the moment, and that grows over time. Yes, you did read that right, I really did say half a terabyte.

It also spikes somewhat alarmingly when we do a major release (indeed, the first time this happened, our ISP actually contacted us to let us know that something unusual seemed to be going on with our server :–)).

Obviously if you’re burning bandwidth like we do, you’re going to need your own dedicate server. Another good reason to avoid disk utility software if you’re thinking of going indie.

Graphics

I actually do all the graphics for our products, at the moment. I think I broadly agree with the remarks of the guys this evening that this might not be the best use of my time, but on the other hand I quite enjoy doing it. It’s a relaxing change from writing software, and I don’t need to explain to someone else how I want things to look.

One thing that may well change that, however, is the new resolution independence. My talents in this area are sadly not unlimited and whilst I can do a decent enough job of most things given enough time, the new 512x512 sized icons are pretty hard. 128x128 was difficult enough, but with sixteen times the number of pixels, it takes a lot of detail to really look good. I doubt I could do as good a job as whoever drew the icon for Panic’s latest app, Coda.

Similarly, I noticed recently that some of the other Mac developers’ sites look really good now. Ours is currently a bit dated (though we’re working on a replacement, which will make it easier to change the appearance, amongst other things) and I think maybe the time is approaching where we need to talk to some professional graphic designers to really get it looking and feeling good. Recommendations would be appreciated, if anyone knows anyone :–)

Having just read John Gruber’s thoughts on the WWDC announcements, and having spoken to a few people at WWDC myself, I thought I’d stick in my two cents on one or two of the points raised in his post.

First off, the Dock. I quite like the new Dock, even when it’s sitting on the left or right hand side of the display. Sure, the effect is slightly less dramatic when it’s on the side, but I’m not sure it really looks “like crap”. Of course, it’s worth saying that whether or not something is pleasing to the eye is quite subjective, but I think John’s taking it a little far here. Also, I wonder if he’ll feel the same way about it in 6 or 12 months’ time.

Second, John implies that he doesn’t think the Cover Flow view in Finder will be particularly useful. I must admit that was my initial thought also, but since then it has grown on me slightly. The benefits of using Cover Flow in Finder, I think, are the fact that you get a decent preview of the thing you are opening, and that, unlike the icon view (which can provide a reasonable preview if the icon images are set that way), scrolling through Cover Flow is a 1-D operation, hence significantly easier in many ways. Sure, it’s still eye candy, but the more I think about it, the more I think it might actually be useful.

Of course, I’ll have to see how it pans out when I actually try to use it, and whether I prefer it to the other views.

Well, I’m now in San Francisco for WWDC 2007. I’m pretty tired after over 10 hours of flight, not to mention an overnight stay in the Heathrow Renaissance (which was very comfortable, aside from not having any hot water in the bath/shower in the early morning when I was getting up, and the usual problems of not sleeping well in a new place and/or when worrying about making certain to get to the airport on time).

Still, I’m looking forward to WWDC this year. I was last here in 2005, but I think 2007’s conference should be much more interesting, both for me and for my company (I have a distinct feeling that Apple are going to do something that’s awkward for us, again… though I should add that we do expect that to some extent, and all the things that fall into that category are good for end users).

Apparently, Apple’s new DRM-free music embeds your name and e-mail address in the music files, presumably so that it’s easy to find out whose copy of the file was illegally distributed (when it inevitable is).

A MacNN article is quoting Fred von Lohmann, one of the Electronic Frontier Foundation’s senior intellectual property attorneys, as having said that

Some of the privacy problems, in light of this, is [sic] that anyone who steals an iPod that includes purchased iTunes music will now have the name and e-mail address of its rightful owner.

Forgive me for pointing out the obvious, but people commonly mark their name and address onto items that they don’t want to lose, presumably on the assumption that it’s more likely that something will be lost and then found (and maybe handed in) by an honest individual, rather than stolen.

In fact, many devices (iPods included, if I remember correctly) have special options to let the user put their name and address in them.

I’m sure the response from the “privacy” advocates will be that the user has the option to set these settings, whereas they have no choice over whether this information is embedded in their music files or not. But even if that’s true, it’s a very weak argument indeed.

(For those who are wondering, I put privacy in quotes when I talk about “privacy” advocates, because most of them are not, in fact, advocating privacy. Instead, the majority advocate anonymity, which is quite different and has many effects that are detrimental to the rest of society [for instance, it’s much easier and safer to commit fraud and other crimes if you have anonymity…]. Fred von Lohmann’s comments suggest that he is one of these anonymity advocates.)

What a neat idea! The authors of the 1Passwd password storage tool have come up with an ingenious and attractive way to present customers with a software license key… “License Cards”.

Here’s a sample (reproduced from their blog post):

Now I can’t say we’ll be running to support this new style of license key, given that we’ve put a fair bit of effort into our existing set-up. I also take issue with some of the remarks about software activation (especially the one about how programs using it “essentially spy on [their] users”, which, frankly, is both untrue and needlessly inflammatory).

That said, I like the idea of drag & drop license keys. I also like the idea that it’s possible to make them look pretty (in fact, why not offer them with a variety of attractive backdrops?). And whilst it will cause a small amount of pain for users who keep their keys organised in a text file, it will also cause a large amount of pain for software pirates (e.g. the “serialbox” will have to change significantly if it is to cope with these files).

I do wonder whether their technique is based on steganography or simply on public key encryption with data stored in their own JPEG chunks (or in the EXIF information). The former has advantages (e.g. it would be possible, with a good implementation, to print the card out and then recover a usable card by scanning the print-out), and would also be robust against poor storage techniques on the part of the customer (such as filing it in a Word document file). However, it is considerably harder to do, so my guess is that it’s some variation on the latter.

Apparently the Mayor of London, Ken Livingstone, has apologised for “London’s role in the slave trade”.

This is every bit as daft as those people who persist in demanding an apology from the United Kingdom for the slave trade. Why do I say that? Well:

• The current population of the country have had nothing to do with slavery.
• The U.K. was instrumental in abolishing slavery in the first place, and indeed the Royal Navy was for some time patrolling the coasts of Africa to stop various other countries’ vessels carrying slaves back to their homelands.
• The African nations supplying slaves were complicit in the trade themselves.
• Many (certainly not all, but many) slaves were well treated and in some cases married and had families with their masters. There are plenty of examples of mis-treatment, to be sure, but ignoring those slaves who (or whose families) benefited overall whilst emphasising those who didn’t is at best iniquitous.

Only the stupid would demand an apology, and only the stupid would give one. My estimation of Ken Livingstone has gone down substantially today.

Oh, and if you still can’t see why it’s so silly, let’s ask the Italians to apologise for the Roman Empire (which, incidentally, had lots of slaves). Or how about we ask the Muslim world for an apology for whatever unpleasant acts were committed by their kin during the 7th or 8th centuries in Spain? No?

It actually makes me cross that we have public figures apologising for things like this, because it lends credence to the idea that they should be doing so, and legitimises the demands of some of the groups of people calling for apologies for this, that and the other.

It’s been irritating me for ages that it isn’t possible to straightforwardly get the network address(es) of the machine you’re running on from a Python program.

Well, if you’re running Mac OS X, or probably some of the various other UNIX-like systems, now you can (here’s the source code).

Here’s a quick example of how to use it:

>>> import netifaces
>>> netifaces.interfaces()
['lo0', 'gif0', 'stf0', 'en0', 'en1', 'fw0']
>>> netifaces.ifaddresses('en0')
{18: [{'addr': '00:12:34:56:78:9a'}], 2: [{'broadcast':
 '10.255.255.255', 'netmask': '255.0.0.0', 'addr': '10.16.1.4'}],
 30: [{'netmask': 'ffff:ffff:ffff:ffff::', 'addr':
 'fe80::123:4567:89ab:cdef%en0'}]}

Note that presently this has only been tested on Mac OS X (the SIOCGIFxxx ioctl()s have been tested, apart from SIOCGIFHWADDR, which doesn’t exist on OS X).

Note also that it won’t work on Windows. You’d need to use the Windows Sockets functions to get similar functionality on Windows, I think.

Update (2007/03/18)

It works on Windows now too! There are also pre-built binary versions for Windows (Python 2.4, Python 2.5), and also Mac OS X. But do yourself a favour and use easy_install:

easy_install netifaces

(You can get easy_install from the PEAK Developers’ Center if you don’t have it already.)

The Windows code can currently only return IPv4 addresses and MAC addresses; also, since Windows doesn’t define AF_LINK, I’ve defined it in netifaces for compatibility.

Update (2007/03/20)

I’ve updated the code so that it builds on Windows with MSVC as well as with GCC. Also, I’ve added support for Linux (which lacks the sa_len member in struct sockaddr, making getifaddrs() somewhat harder to use sensibly).

I’ve also build some more binaries:

Python 2.4/Mac OS X 10.4
Python 2.4/Win32
Python 2.5/Win32
Python 2.4/x86 Linux
Python 2.5/x86 Linux

Update (2008/02/24)

Christian Kauhaus pointed out that the PPP interface on Linux sometimes results in a getifaddrs() record with no address, which causes a crash. Also, Python’s egg selection mechanism meant that the Linux binaries were a nuisance for those with older versions of Linux, so I’ve removed them.

Update (2009/03/09)

Olivier Bourdon very kindly contributed some changes to make netifaces work better on Solaris. I have now merged these in, so Solaris users should no longer need to use the separate patches listed in the links below.

I have also build new binaries for Windows users using Python 2.5 and Python 2.6. If you are still running Python 2.4, please use the older links above (the old version works just fine).

Update 2011-10-14

I’ve moved netifaces to its own page. Please go there to download it.

Last night there was a lunar eclipse, which I was lucky enough to be able to photograph through my telescope. I was a bit concerned that the weather wouldn’t hold, but the only problem I had was significant dewing in the run up to midnight.

Anyway, I combined the images into a single montage, showing the Moon before the eclipse, then in two stages of partial eclipse, and finally in total eclipse. The orange-red colour of the Moon in the latter two stages was really striking, I think you’ll agree.