Since iOS apps are now worth a billion dollars, here’s a few design notes worth bearing in mind when writing your new app:

• Users love receiving push notifications, and love it when you take them to the appropriate page in your app, but they hate it if they see the notification there. Make sure that the page you show contains stale information and does not automatically update to show the notification they just tapped on.
• Increase the number of times users open your app by keeping them in a continual state of confusion as to whether they have any unread notifications. At no time should the notifications shown in the iOS Notification tray, the number of notifications shown in the app icon badge, the number of notifications in your app’s own button badge for notifications, or indeed the list of notifications in your app match.
• For additional bonus confusion, none of the above should match the set or number of notifications the user would see if they opened the notification list on a computer.
• Users love pulling down to refresh. Even if your app is only ever used in a “read new things” kind of mode, always force the user to pull down to refresh, never update for them.
• Your app is only ever going to be used online, on a super-fast internet connection. Never cache data between invocations. Always clear the screen when loading the new data, users love seeing a spinner and a “Loading” message when on a slow connection.
• If you build your app around WebView you may be forced to accept that there will be some caching, fight against it and avoid a consistent experience at all costs by never saving this cache between invocations. Since it’s almost random whether your app will remain in memory between uses, this means it will be almost random whether your user sees stale cached data (which you don’t auto-refresh, obviously) or a white loading screen while you pull all new data.
• Tap targets should be as small as possible, testing in the Simulator with your mouse proves that Apple’s 44px guideline is way too large!
• The app should regularly reflow its content so that tap targets move under the user’s finger between the time they start their finger moving and the time it reaches the screen.
• Using a WebView for your app is great, the lack of JIT and other performance improvements means you don’t need too many servers to serve content to your app. Users love it when shared photos show up as black boxes because the servers are too busy.
• Using a WebView also means you can continually adjust the layout of your page. For the ultimate rapid deployment, never cache resources such as CSS or images client-side. Users love that retro look and feel when your page renders without them on a slow connection.
• Your app probably has to let users post content too. Users are always on fast, reliable data networks. Don’t worry about handling error cases, timeouts, etc. it’s ok to just throw an error, and ideally throw away their post too. Never double-check whether the post succeeded, for that to happen and the response being lost is impossible.
• Whenever Apple release a new API feature, make sure you update your code to take advantage of it. Apple’s documentation can be kinda waffly though, don’t bother reading all of it, you never need to handle the edge cases like someone taking a phone call on their phone (who does that?) or receiving a notification while you’re dragging your neat side bar out. Users love it when that side bar sticks half way, it’s hilarious.

For a perfect score on all of the above tips, I highly recommend taking a look at Facebook’s iPhone app.

Not just the festival, but my project to write a short story or part thereof every day of October and publish them on the website. See my blog post from a couple of weeks ago for more information

All of the stories are now written and published at http://netsplit.com/halloween/ - up to and including today’s. It’s a good feeling to be finally finished. I’ll leave them up for at least a little while longer before I decide what to next with them, a round of editing and tidying up or two is certainly in order; and my current plan is to publish them collected together in printed or eBook form if people want it.

But until then I have a new project…

…I’m going to be taking part in NaNoWriMo. For those that have not heard of it, which included myself until a month ago, it’s a competition of sorts to write a 50,000 word (minimum) first draft of a novel in the month of November.

I’ve had the idea for the story for a couple of years now, and what with wetting my apetite for writing again with the October project. I’m eager to get started on it. Now I just need to wait until midnight…

Readers of this blog will mostly know me for the software I’ve written, most likely Upstart or my work on Ubuntu, but there’s another kind of writing I enjoy doing and it’s something I haven’t taken much time to do in the last few years.

Like everyone else I had to do some creative writing at school, but I really enjoyed it and took it quite a bit further writing many short stories over the years.

A friend of mine is taking part in NaNoWriMo this year, and the two of us discussed ways of practicing and, most of all, warming up for it. After all, writing over 1,650 words of a novel a day is no mean feat to go into stone cold. She’s been using 750words.com for a while, and I suggested she use that to write short stories along the lines of her planned novel, but not to be used for it, to practice.

Discussing it really fired up my desire to do some writing again myself, so I decided to join her. But obviously rather than copying, I decided to do something completely different in tone.

Each day in October, leading up to Halloween, I’m writing a short story myself. Since that’s a spooky event, I’m vaguely sticking to a horror theme for the stories. I say vaguely because it’s quite easy to slip from horror to other genres, such as science-fiction or thrillers, but the intent is certainly there that these all have a darker theme than usual.

I’ve also been using 750words.com for the most part, with an aim that each story be a minimum of that in length. One of the most interesting outcomes is that the earliest stories were hard work to reach 750 words from a simple idea, whereas the latest ones easily reach 1,000. In fact my latest story is almost twice the minimum length.

But at the end of the day, they are roughly 3-5 pages each and since they’re posted and published each day, they’re more akin to first drafts of ideas than polished works. I remember reading once about an author who would pin up the pages of a story he was writing to a shop window as each one came off the typewriter (Google tells me this was almost certainly Harlan Ellison), I like to think I’m doing the Internet-era equivalent.

Perhaps they will give some people joy and delight, or perhaps they will give some people nightmares. Even if not, I’m enjoying writing them!

You can read those so far at http://netsplit.com/halloween/ in all the usual formats, and check back every day or so for new ones if you like what you read.

Sorry for the spam folks, I’ve no idea what happened there, for some reason WordPress decided it was going to keep making duplicates of the most recent blog post.  I have no idea why, but it does seem to have stopped.

One of those unusual tests you sometimes need to do is to determine whether a given directory on the filesystem is a mount point for another filesystem.

A good approach to do this is to compare the directory with its parent directory, specifically the device ID as returned by the stat() system call.

The following code would work:



stat (path, &path_stat);

parent = dirname (path);
stat (parent, &parent_stat);

is_mountpoint = (path_stat.st_dev != parent_stat.st_dev);

If you want to know more information about the filesystem mounted there, you can use the statfs() system call. This returns, amongst other interesting details, the filesystem type.



if (statfs (path, &statfsbuf) == 0)
    is_ext3 = statfsbuf.f_type == EXT3_SUPER_MAGIC;

Today is National Coming Out Day in the UK, I understand that National Coming Out Day was actually yesterday in the US; apparently an International Coming Out Day is hard or something.

I am gay.

That doesn’t really count as coming out though, if I am anything it’s openly gay. In fact a friend once joked that I manage to include a reference to my sexuality in every blog post or e-mail I write, and that every Twitter post of mine ends in “still gay”.

Maybe he’s right, but if it is, it’s probably subconsciously deliberate.

I confidently predict that there will be no surprise coming out statements this year from anybody in the public eye. Not even from those who don’t exactly do a good job of hiding it, yet deny it every time they are asked. You know who they are.

I think that’s quite sad.

I strongly believe that is the duty of those in the public eye to be open about their sexuality.

Firstly from a positive point of view, everybody needs role models. A young man or woman coming terms to their own sexuality will be able to do much easier knowing that there are public figures they respect who are comfortable with their own sexuality and open about it.

And from a negative point of view, every public figure who’s denying their sexuality is reinforcing the idea that you should not be comfortable with it and that being open about your sexuality will cause you problems.

Many celebrities, for example, claim that the reason they haven’t come out is because they’re afraid of what it will do to their careers. This is not only ironic, since they’re just perpetuating the problem, but clearly nonsense since there are a number of extremely well known and loved figures who are openly gay.

So this is why I’m open about it.

I want to make sure that any new members of our community who are coming to terms with their own sexuality can be assured that this is not going to cause them a problem.

(Still gay)

The ongoing debate about Mark Shuttleworth’s keynote at the Linux Plumber’s Conference has been bothering me for a little while now, but I’ve been avoiding posting until now.

Before I do, let me make one thing clear (as if it wasn’t already), I am a gay man.

Mark is a heterosexual man. In his LPC keynote he is accused of sexism because in his keynote he said that making Linux easier to understand would make it easier for him to explain what he does to girls.

Now, let’s pretend for a moment that I’d gave that keynote. Let’s pretend that I’d said that that making Linux easier would make it easier for me to explain what I did to boys.

Would there be this uproar?

Oh they’d be an uproar alright, but it wouldn’t be about sexism – the homophobic right of our community would be throwing their bibles out of their prams with vigour!

But nothing about sexism!

In fact the very people who are currently attacking Mark would be defending me as a gay man for right to say things like that. And if they didn’t I could cheerfully accuse them of homophobia.

And that’s why this bothers me.

If Mark was sexist, than he’s sexist for only being attracted to women and understandably caring what they think of him. That’s not sexism, that’s biology!

Sometimes a spade is just a spade.

Sometimes when a man says that he likes girls, HE LIKES GIRLS!

If your complaint is that he uses “girls” to mean “women” then you need to get (a) in touch with some mystical arbiter of the colloquial English language & (b) a grip.

I suspect this has ended my chances of ever being offered a Keynote (not that I ever have) and that Linux Today will now claim I should resign (I don’t work directly for mdz, but I have a tremendous amount of respect for him) then so be it.

And this is why the outcry bothers me.

My recent series of posts in which I had some difficulty with GIT (1, 2, 3) have garnered a lot of interest, and generated some discussion.  Many of the replies saw the funny side, which is nice as I was hoping to be at least amusing (rants are, after all, a form of entertainment) and more than I expected sympathised.  Many tried to help by giving me a sequence of commands that might work, ironically often the exact same commands I used in my original post.

And many told me I was an idiot, and that they had no problem; and that I should learn how to use GIT instead of just stabbing at guesses.

Those made me realise what the fundamental difference between myself and them are.

I don’t want to use a revision control system.

It follows that if I don’t want to use one, I certainly don’t want to waste time learning one!  I don’t want to use a text editor either, again it’s just something that gets in the way of what I really want to do.

I want to write code, and I want to fix bugs and test the fixes.

Actually, I don’t really want to fix bugs; but it’s one of those things you have to do as a responsible software author and maintainer.  Now, I sadly can’t just write code by thinking about it.  Even though I use zsh, holding down the TAB key just doesn’t write my code for me, so I have to use a text editor.

And I hate them, especially emacs, which is the text editor I use.  I keep hoping that one day Anjuta or something like MonoDevelop will be usable for writing and debugging C – but alas, that day has not yet come.  (Incidentally, if a developer would like some constructive criticism from my side, I would be perfectly happy to do give it – just grab me on IRC).

Now I don’t have to use a Revision Control System, unlike a text editor which is somewhat essential, but there are a lot of advantages to using one.  In particular, I think I have two primary use cases:

1. Keeping a history of my changes
2. Sharing my work with others, and allowing others to share their work with me.

Since I don’t want to use a Revision Control System, it should be as simple and painless to use as possible.  I have probably a dozen common actions that I do; so each of these actions should be just one command, with no options or flags to make them do the right thing.  For bonus points, these commands should be obvious and ideally have aliases for the similar commands in other systems for easier learning.

Here’s the first set:

• get a copy of some source code, to which I can make my own changes if I wish
• save my current set of changes to the history
• put a copy of my source code, with changes, somewhere others can get at it
• update my source code with changes made to where I got it from

We could probably call these get, commit, push and pull. Note that I’m not allowing for any kind of add, move or remove command.  Such things are a pain in the neck; my most common preference is just for any changes I’ve made to be committed.  This is probably one big reason why GIT and I don’t get on so well; it’s written for somebody else’s use case where the most common use case is committing nothing.

Since I pretend to like other people working on my software, I’ll need a couple of commands for doing that:

• review the changes somebody else’s source code makes to mine
• add the changes they’ve made to my source code.

I’ve yet to see a revision control system that makes the first one easy, which is sad, because it’s just about the most common operation I do on other people’s branches/repositories/clones; I’d call that review, and then we can call the second one merge.

And then for the last set:

• look at the history of changes
• examine the difference between two versions
• extract a single change, in a format compatible with mailing

We can call these log, diff and show (though ideally diff and show would be just the same command with a revision range or single revision).

I’ve probably forgotten something important, but in general, those are the operations I try and do with a revision control system.  Thus I can create a Revision Control System Hate Index.  The more commands, options or flags it takes to do any of these operations, the higher the Hate Index and the more I’ll loathe it.

GIT scores badly, very few of these operations are a simple command.  Many require pre-configuration, many require options and flags to do the right thing.  And a couple of them are actually multiple commands.

In fact, GIT’s hate index gets increased further, because after a while you realise that most of the top-level commands very rarely do the right thing.  Instead, you start to break down the commands to their fundamentals.  If you’ve ever found yourself using git fetch you know what I mean.

This means that I have to stop thinking about writing code, and start thinking about using the revision control system and what the best way to accomplish the operation that I want is.  This is a fail that only results in hate.

And just for the peanut gallery, I’d like to point out that Bzr has a non-zero Hate Index as well.  In fact, there are misfeatures and bugs in Bzr that make my blood boil just as much as GIT, sometimes even more since Bzr actually claims to always try to do what I mean.

You know what would make me happiest?  If I had a text editor that took care of revision control for me.  Sometimes I wish there was a Linux version of the good old Borland IDE or at least VisualStudio.