They’ve been saying for a while now that an official Aperture Export plugin is coming, and there seems to be a lot of demand. Well, I got bored of them taking their sweet-ass time and threw together my own.

It requires Mac OS X 10.7 (Lion) and Aperture 3.x, and do bear in mind that I made this in less than 48 hours, so it may be buggy and it’s certainly light on features. But, it gets my photos directly from Aperture into 500px, so I’m happy!

You can find out more and download the plugin from GitHub. Enjoy!

Oh, and if anyone loves this plugin so much that they want to get me a gift, well, gifting me a year’s worth of awesome would certainly be appreciated!

Two days after we arrive in the UK, the lens my friend gave us stuck at 17mm and wouldn’t budge. I felt super-bad about this, even though it turned out it was a common problem with this lens.

Still feeling bad about breaking my friend’s lens, I dived right into the tutorial and tried to fix it! Lenses are incredibly intricate, and my first attempt wasn’t so successful - I’d fixed the zoom sticking, but now the focus didn’t work!

Take Two

Tonight, I tried to fix it again, and was successful! The lens’ zoom is a smooth as ever and the focus works too. I was ecstatic, and I looked down to see my dog staring at me with glee, raising his paw as if to say “HIGH FIVE bro, you tha man!”

A couple of seconds later I realised he was actually trying to say “Damnit I’m hungry - give me food!” Still pleased with my dexterity and skill, I went to the kitchen to distribute food for him and ended up with, well, a less than optimal result.

I guess there’s no brain surgery in my future after all.

This routine is lovely and lazy, but isn’t really helping me get stuff done - I have a ton of side projects, I want to play my guitar, I want to occasionally spend time listening to music as a primary activity (rather than in the background while I’m doing something else), etc etc.

It’s also been very easy to fall into the trap of thinking I simply don’t have time to do all these things - I mean, I get home, eat dinner, spend a small amount of time on the computer and now it’s bed time!

Be Selfish!

Recently, I’ve been trialling having an enforced “me time” - one hour per weekday, in the evening, where I’ll stop what I’m doing (within reason!) and go and do one of the above things.

So far, it’s working out really well. I’m fortunate to live in an apartment large enough to have a room available for filling with the kind of toys required for this - so far it’s decked out with a model railway, a fairly decent audio system and a small guitar rack with an amp. Best of all, it’s right at the opposite end of the apartment to the living room and above the entrance hall to the building, meaning I can make a racket without bothering my fiancé or anyone else.

Now I’ve settled into the routine - I’ve been doing this for a couple of weeks now - I’m actually finding that I’m enjoying my evenings way more and I still have plenty of time to do the things I’d normally do anyway - I can eat dinner, faff around on the computer a bit, play World of Warcraft with my fiancé and still have an hour for Me Time. My fiancé heartily approves because it means she can watch her crappy girl TV without me complaining about it.

So, if you’re finding you don’t have time to do the things you’d like to do in your spare time - I’d thoroughly recommend giving an hour of forced “me time” a try - it doesn’t even have to be every day!

There are two reasons why I play games. Only two, and almost by definition they’re mutually exclusive:

1. Because the game is a fun, normally multiplayer, pick-up-and go action/platformer.
2. Because the game has an involving storyline I can engross myself in.

Part of my personality is that I get way too attached to characters in a good story, especially in films and TV shows. Up? Cried. Twice. At the start. That episode of Bones when Brennan and Booth finally tell each other how they feel, but decide to keep apart because they work together? Floods of tears.

This invariably moves over to video games, when the story is good. Unfortunately, video game writing is, as a rule, pretty bad - I have a pile of games that I’ve started playing and left after a couple of hours as the storyline simply hasn’t drawn me in at all. A couple of notable exceptions in my mind are Blizzard and Rockstar.

Major Spoilers for the endings of Red Dead Redemption and World of Warcraft: Cataclysm Ahead! You can safely skip these if you don’t want the stories of these games spoiled without missing the main point of this post.

The key, in games, is to get the buildup right. Red Dead Redemption does this very well - the entire storyline is about the main character chasing down an outlaw for the Feds in order to be reunited with his family. In the mission where you finally corner the outlaw and are closing in, the music slowly ramps up in intensity as you ascend the hill towards him. When he’s finally down, you’re free - the Feds let you go, and you spend the next few minutes riding your horse through a sunset-lit forest towards your family as a perfect song plays in the background. It’s such a wonderful moment, and since I got far too attached to this guy I was once again in floods of tears as I get reunited with my family and play through a few missions getting back into the swing of normal life.

Then? The Feds betray you. A bit cliché, to be honest, but I guess it’s time to take them down too. Then? BAM. You’re dead. I was so shocked by this that I missed half of the cutscene afterwards, scrabbling around on Google to confirm that the main character just got killed. I mean, they never kill off the main character!

When the game finally ends, I feel kinda hollow. I’ve spent so long with this character, reuniting him with his family, and it was all for nothing? Should I feel betrayed by Rockstar for doing this? I dunno, but it’s damn good storytelling.

Blizzard are another company who can tell an excellent story, and in the case of World of Warcraft, the story is even optional. The buildup to Cataclysm’s ending has been literally a year in the making, and a great example of the optional story. If you don’t care about story, you get:

• Dragon burns down your capital city, tears up the world, kills your friends.
• Dragon spends a year or so taunting you while you take down his cronies.
• You finally kill Dragon. Hooray!

… and the whole thing is thoroughly enjoyable. If you do care about story, though, there’s a huge, deep, subplot involving the dragon forming a cult to infiltrate the upper powers of the land, twisting them to his will.

End Spoilers!

You Play World of Warcraft?!

The interesting thing about enjoying the story in video games is that a lot of people see them as children’s toys or nerd obsessions. It’s completely normal to sit and read about adventures in a fantasy world in a book, but from a game? I actually find that older generations can understand it better than younger generations who grew up in schools where computers were using by “the nerdy kids” while they ran around kicking balls around feeling all masculine.

This mentality is even present in my place of work, which is kinda surprising since I work at a tech company with a very high level of tech-savvy people. We were eating lunch one day when I was discussing Dungeons and Dragons with a friend. I’ve never played it, but I’d love to try, and my friend was the same. Someone else on the table whom I’d never met before cried “Dungeons and Dragons?! Oh my God, you guys are such nerds! Next you’ll be telling me that you play World of Warcraft!”. The rest of the table simply sat there staring at him in stunned silence, partly because it’s the first time we’d heard the word “nerd” used as an insult from one of our own, and partly because they all played either Dungeons and Dragons, World of Warcraft, something else similar, or all three.

The Inevitable Happens

I am completely invested in the story of the Warcraft universe and the characters within. I hate Garrosh for killing Cairne. I’m angry at Varian for acting like a complete asshole while his son grows out of him and looks destined to become a greater king than he’ll ever be. I was absolutely devastated with what happened to the Dragon Aspects after we killed Deathwing.

This passion for storytelling and living the story through games is what’s drawing me to Dungeons and Dragons. I was joking around yesterday and started making up a story about a dragon called Sid who was lonely and wanted to make friends with the local villagers, only to be chased out of town after he hiccupped and accidentally burned a family’s house down. After I’d finished telling the stupid story (Sid brought the hungry villagers some sheep he’d been keeping in his cave and won their friendship), I carried on thinking about the world this dragon might live in, the people in there, the geography of the place and so on.

I’d like to think this would make me a good Dungeon Master in D&D - the idea of leading others through a world and stories I help create sounds very appealing. So, the other day I picked up a D&D Starter Kit and started playing through it.

A few friends are also interesting in playing, so hopefully this will amount to something good!

A couple of weeks ago, I registered a nifty new domain: ikennd.ac. It’s perfect - short, sweet, and to the point. The problem is, though, that my blog had a big “danielkennett.org” logo on the top of it, and no other title or strapline. Replacing it with an “ikennd.ac” logo seems silly since I’ll be keeping the danielkennett.org domain alive for linking, and I was stumped.

That is, until today. A superb conversation popped up on Spotify’s internal IRC from Tobi, one of the designers, a slightly trimmed version of which I present here (I’m dan):

• tobi: RIGHT
• tobi: Time for weird theory
• tobi: WHAT IF
• tobi: “broken” was spelled “borken” from the beginning
• dan: ?!
• tobi: Then to enforce that something was broken, they broke the word
• tobi: IE, they spelled “borken” -> “broken”
• dan: But if it was spelled that way from the beginning, it wouldn’t be broken
• dan: “borken” would be correct
• tobi: yes, borken would be correct
• tobi: NOWADAYS “broken” is correct
• tobi: and borken is broken
• tobi: but it may be turning back!
• dan: And then hundreds of years later, people like you would be all “WHAT IF they spelled it ‘broken’ to break the word?!?!”
• tobi: Exactly
• dan: I should make a book of Tobi’s “theories”
• tobi: dan: Best book ever
• dan: Call it “Tales of an unchecked mind”
• dan: HOLY SHIT
• dan: http://www.google.com/search?&q=%22tales+of+an+unchecked+mind%22
• dan: DIBS
• tobi: dan: hahaha
• dan: I can’t believe I came up with a unique title of something that sounds somewhat good
• dan: That’s totally being my blog’s title :-P
• tobi: :-D
• tobi: dan: butbutbutbut I should use that!
• dan: Too late
• tobi: you don’t have weird enough theories
• dan: COPYRIGHT
• dan: ©

In it, I spontaneously came up with the phrase “Tales of an unchecked mind”, which is both a cheesy tagline and perfect for a blog, but more importantly at the time of writing had ZERO results on Google when the exact phrase was entered!

I changed it slightly to “Tales From An Unchecked Mind” and am now using it as the title for my blog. I’ve been wanting to make my blog more personal for a while now, including more writing about non-tech stuff along with an about.me-style page with my bio on it, and I think the new title will fit well.

Well, I’ve decided to take this into my own hands. In my previous post I mentioned that I’ve got a “more ambitious” Arduino project in the works, and today it arrived:

It turns out that interfacing with an RC is dead-simple - both the servo and the speed controller use the servo electronic interface, which the Arduino has libraries for.

Over time, I want to be able to solve the following challenge:

Here’s a GPS coordinate: (x, y). Get there.

The constraints of the challenge will be along the lines of:

• The environment will be a fairly open area with large obstacles (fields with trees, etc).
• The car won’t have to worry about staying on roads.
• The car should take a reactionary approach to navigation and not do a grid-search of the area.
• The car should be able to go at a reasonable speed (> 10km/h or so).
• The car should recognise potential dead-ends and stop in time.
• The car should recognise when a fatal problem (like ending up upside-down) has occured and give up.

Given those constraints, the car will need at least the following sensors:

• GPS
• Gyroscope
• Long-ish range distance (sonar or otherwise)
• Long-ish range wireless for diagnostics and emergency-stops

Thankfully, all of those are available for the Arduino. A friend of mine immediately started talking about advanced algorithms and video analysis when I mentioned this idea, but I hope to keep it much simpler than that, and given the environment the car will be in I hope to be able to pull off something with this project.

This will be a long-term project, especially since winter is rapidly approaching and if it’s anything like last year’s we’ll be knee-deep in snow in less than a month. Still, I’ll build the car soon and at least get it moving a bit under Arduino control.

Today, we’ll be tidying up the hardware side of the project from the current sprawling mess of wires:

To a neat little box:

Creating an Arduino Shield for DIODER LED Strips

An Arduino shield is a circuit board that connects to an Arduino and contains a certain number of electrical components that perform a certain task — you can buy pre-made shields to give your Arduino an ethernet port, a display, and so on. We’re going to make a shield that stacks on top of the Arduino Mega 2560 and you can connect the LED strips to.

On top of the things you already have, you’ll need the following (Links to Swedish store):

• Soldering Equipment. If you haven’t soldered electronics before, get a strip board and some spare components like resistors to practice with first.
• Assorted lengths of wire. [Link] [Real Link]
• 1x Box for Arduino. [Link]
• 1x Proto-Shield for Arduino that includes stacking components. [Link]
• 16x Right-Angled Strip Headers [Link]

Rather than step you through creating the board, I’ll simply leave you with the circuit diagram to implement and some photos of my finished board.

A few notes:

• You’ll notice that the circuit diagram is a bit different to the one originally presented in the first part of this series. This is to make creating a circuit board easier, and I’ve gone back and updated both the original post and the code on GitHub for this new layout.
• You can probably make your board look way neater than mine!
• The connector pins for the LEDs are right-angled because there’s not enough space in the box for vertical pins and the LED connectors. Angle the two sets of pins that aren’t hanging off the board upwards slightly to make connection easier.
• You can download a PDF of the diagram here.

Once you’re completed the board, it will stack on top of the Arduino Mega just fine. Cop a bit out of the box to allow the Dioder cables through, and you’re set!

Moving Forward

As before, let me know on Twitter if you’d like to share and thoughts or idea about this project. Now we have a nice, neat box, in a couple of weeks I’ll post the final part of this series — a System Preference pane with accompanying service to let the lights respond to various system events, falling back to the ambient lighting when nothing else is happening. After that, I’ll take a bit of a break before starting the next, more ambitious, Arduino project.

Have fun!

A couple of weeks ago, I wrote a post detailing the process of combining a set of colour-changing IKEA LED strips, an Arduino, a few simple electronic components and a lot of nerdiness into a project that allowed you to control the colour of the LEDs though a simple application running on your computer.

Over the coming weeks and months, I’ll be presenting cool things you can do with this project here on my blog. However, I wasplanning on working up to this post, but since lots of people were enthusiastic about this particular part (as can be seen from the screenshot of my Facebook stream to the right), I jumped ahead a bit.

Now, Philips have a very similar system in a lot of their TVs, and as a colleague at work who called me “Mr. Patent Infringer” pointed out, they probably have a buttload of patents covering their technology.

So, please allow me to present…

An Ambient Lighting Solution Similar To But Legally Distinct From Philips® Ambilight®

So, what’s the challenge here? Well, actually, the core challenge is pretty damn simple:

1. Sample the screen.
2. Push an appropriate colour based on the edges of the screen image to the lights.

Philips’ hardware also does a fuckton of image processing to smoothly animate between colours and even provides an “aggressiveness” setting to control how sensitive the LEDs are to colour change. I’ll be leaving this as an exercise to the reader for now.

As always, all the code is available at the project’s home on GitHub.

First Attempt: Who let *him* near a computer?

So, I’m not going to lie — my first attempt at this, was, well, lame. For a start, I learned that if you leak a screen’s worth of pixel data every time the screen refreshes (that’s 2560 x 1440 x 4 bytes = just over 14Mb per frame at up to 60Hz), things go very bad very quickly. Once that was fixed, my technique was:

1. Register for screen update callbacks using CGRegisterScreenRefreshCallback().
2. Every time I got one of those, render the entire screen image into a new buffer.
3. Loop through allof the pixels in the top, bottom, left and right 1/4 rectangles of the image buffer.
4. Average the RGB values therein.
5. Push those to the Arduino.

As you might imagine, that method is rather inefficient. In fact, it’s downright idiotic, and took nearly 60% of my CPU all the time.

As the implementation matured, various optimisations of course took place — only an idiot would allocate a new buffer each time the image changes, for instance. In addition, the CGRegisterScreenRefreshCallback() callback looks like this:

void screenDidUpdate(CGRectCount count, const CGRect *rectArray, void *userParameter);

Which provides a lovely rect array telling you which parts of the screen image changed, which is perfect since we only care about parts of the image.

Final Attempt: Passable, I guess

As I attempted to improve the efficiency of the project, I tried only sampling every fourth pixel, scaling the image down, etc, since we obviously don’t need every single pixel sampled to get a single average colour that’s good enough for the lights. However, the very act of rendering the screenshot into a pixel buffer was by far the most intensive part of the whole thing. I was publicly fishing for help on Twitter when @uliwitness reminded me that Core Image exists.

A few minutes later, I’d replaced 90% of my code with a call to a Core Image Filter called CIAreaAverage, which calculates the average colour of a given image. Since Core Image is badass and much better than me, this actually causes all the work to be kept on the graphics card and caused CPU usage to tumble.

The final project for this post contains two methods of calculating colours:

Pick A Pixel: Literally pick a single pixel near each edge of the screen and use that. Not very clever.

Average RGB: Use Core Image to calculate the average colour of the edge rectangles of the scree as discussed above.

I was also planning on doing an Average Hue method too, since I was expecting Average RGB to give brown every time (possibly a side-effect of always getting shades of brown when mixing colours in art at school). However, Average RGB works just fine so I never implemented it.

Project Status

As of now (commit b3a1b17c038458d498d551a18d120435daf9f778), the project has undergone a few improvements since Part 1 of this series:

• Removed AMSerialPort for my own DKSerialPort class. AMSerialPort was buggy and didn’t work with connection speeds over 9600 baud. DKSerialPort is also a lot smaller.
• Created a class called ArduinoDioderCommunicationController, which abstracts away all the work of communicating with the Arduino running the included sketch. This allows future projects in this series (and you, of course) to drop in the class and just push colours without caring about how it all works.

Of course, I have to include a video of this project in action. The colour changing is a little crappy since I don’t do any smoothing, and unfortunately my camera picked up an odd flickering which isn’t visible by the naked eye, but you get the idea:

Moving Forward

As before, let me know on Twitter if you’d like to share and thoughts or idea about this project. In a week or two I’ll put up another post discussing some more code to make the LED strips respond to system events and so on.

I hope this is enough to get you started, though. Have fun!

A few weeks ago, it came to my attention that IKEA do a set of colour-changeable LED strips. I’ve been looking for a decent way of providing some lighting behind my computer to reduce eye-strain for a long time, and these seemed perfect:

I was very pleased with them, but no self-respecting nerd would stop here. Especially one who’s seen Philips’ Ambilight technology in action!

Over a series of blog posts, I’ll be explaining how I built a simple controller for IKEA Dioder lights using an Arduino Mega2560 unit, then moving on to explore various ways to utilise this control in software for fun and awesomeness.

In this post, I’ll be building an Arduino layout that controls the Dioder LED strips, programming it to listen to messages on its serial port and set the LED strips’ colours accordingly, then making a simple Cocoa application in Xcode that sends messages to the unit to match the strips to colour wells in a window on-screen.

Note: If you see a paragraph starting with Tangent:, you can skip it without losing information on how to build this project.

I care not for your long and boring descriptions! Just give me the code and wiring diagrams!

You can grab the code over at the project’s homeon GitHub, which includes both Arduino sketches for uploading to the device and Xcode projects for controlling it. The Arduino sketches require the Arduino software and the Xcode projects were written on Mac OS X 10.7.

You can download a PDF wiring diagram here.

Enjoy!

Part 1: Creating the Arduino-based hardware layout

IKEA sell Dioder lights in a number of configurations — I went with the set that includes four multicolour strips, a control box and a power adapter (Store links: Sweden/UK/USA). The control box and power adapter won’t be used once they’re connected to the Arduino, though.

The Dioder LED strips have 12VDC on a common anode, with three return paths for the red, green and blue channels.

Ingredients (links to Swedish stores):

• 1 x Arduino Mega2560 [Link]
• 1 x 12v AC-DC Adapter [Link]
• 1 x A-B USB Cable [Link]
• ~40 x Male-Male Jump Cables (I got four packs of ten) [Link]
• 2 x ULN2003 DIP-profile chips [Link]
• 1x Breadboard with at least 20 lanes [Link]

The layout here is fairly simple — power the Arduino with the 12V power adapter, then tap into that for the anode on each LED strip. PWM pins 2-13 (0 and 1 collide with serial communication, which we’ll be using on this project) on the Arduino are connected to the ULN2003 chips, which act as relays for the red, green and blue cathodes from the LED strips. Finally, the ground pins on the ULN2003s are connected to the Arduino’s ground to complete the circuit.

Below are photos of the completed unit as well as a diagram of the wiring. You may notice that the wiring in the photos isn’t quite the same as in the wiring diagrams — that’s because I miswired the project when I took photos of it. All code and future projects are based on the wiring diagram.

You can download a PDF of the diagram here.

Part 2: Programming the Arduino

Rather than stepping through the process of listening to the serial port and controlling the PWM pins, I’m going to jump straight to what I implemented for the Arduino to listen to messages on its serial port and set the PWM output values accordingly. However, if you haven’t programmed Arduino before, I strongly recommend visiting the Arduino reference guides and looking at the sample projects included with the Arduino software to learn how it all works — it’s a lot of fun!

The protocol I implemented is very simple — two constant header bytes, 12 “body” bytes (one for each red, green and blue pin over four separate LED strips) and a checksum byte (a bitwise XOR of all the body bytes).

A message setting all connected LED strips to white/GBR(255,255,255)

Tangent: Originally, I’d implemented the protocol without headers or checksums — the Arduino would listen to the serial port and push each 12 bytes it got to the PWM pins. However, this was such a dumb idea — if you accidentally sent the wrong length of data or some other app sent data to it (which happened more than once), you’d never be able to get it back in sync! You can find the Arduino sketch that listens for that “protocol” in the sample code repository linked below at Arduino Projects/FourChannelRGBDumbListener/FourChannelRGBDumbListener.pde. Don’t use it, though — it’s dumb!

You can grab the finished Arduino sketch over at the project’s home on GitHub, at Arduino Projects/FourChannelRGBSmartListener/FourChannelRGBSmartListener.pde.

Part 3: Creating a Cocoa application to send messages to the Arduino

By now, you should have an Arduino successfully controlling your Dioder LED strips. You can test this by connecting it all together (make sure you connect the 12V adapter to the Arduino or the LED strips won’t be powered) and switching on the Arduino — the Arduino sketch I wrote will switch all four strips to white until told otherwise over the serial port.

My Dioder LED strips are attached to the back of my iMac as shown in the photo at the start of this post, so I made this very simple application — choose the Arduino’s serial port from the menu, then change the colour of the colour wells — the corresponding LED strip will change colour to match!

The full Xcode project can be found over at the project’s home on GitHub, at Xcode Projects/Dioder Colour Wells/Dioder Colour Wells.xcodeproj. Just to show how cool this looks in real life, I recorded a video to show it off:

Moving Forward

Hopefully you’ve got a few cool ideas on what to do next — let me know on Twitter if you’d like to share! In a week or two I’ll put up another post discussing some more advanced code to make the LED strips respond to system events and so on. A little bit further down the line, we’ll start to get to the juicy stuff like live image processing for having the LEDs react to what’s on screen.

I hope this is enough to get you started, though. Have fun!

One year ago yesterday, my fiancé and I pulled up outside an apartment a few kilometres south of Stockholm at 11am. We’d just spent the last four days driving through equally driving rain from the UK through France, Belgium, Germany, Denmark and Sweden. We’d camped each night in the rain. We were wet, our tent was wet, our stuff was wet.

We breathed a sigh of relief. We were happy to finally arrive, even through our journey had been gruelling but a lot of fun. We’d stopped by the Nürburgring and the world’s largest model railway on the way, both of which were amazing. We took a 15 minute break before hauling all of our stuff up three flights of stairs into our apartment.

We’d just moved to Sweden. We were both nervous and excited about the time ahead, comforting ourselves with the fact that we could “just move back to England” if it didn’t work out.

The Present

One year later, and we’ve just moved into another flat — one with no maximum term, which we’re happy about since we can stay here for decades if we want to. Both my fiancé and I have jobs at Spotify, which we’re both enjoying more than we thought a day job could be enjoyed.

Living in Sweden is completely normal now. We get up and go to work, then come home again. Drive to the supermarket to do our shopping. Have LAN parties with our friends. Living in the UK seems like a distant dream — not a good one, at times.

Occasionally I’ll be doing something thoroughly normaland the enormity of the last year will smack me in the face. Last time it happened, I was driving, in my Volvo, to IKEA. A completely normal, British thing to do. As I was driving, I noticed that the forest was nothing but pine trees, which I thought was odd. Then, I remembered. “The forest is nothing but pine trees because I live in fucking Sweden!” A smile spread uncontrollably across my face as I remembered the year and a half long buildup to moving, then one day packing as much stuff into the car as we could and starting the trip across Europe.

I still can’t decide if what we did was “big” or not — I’ve met quite a few people who travel between countries a lot, so if you ask them what we did is no big deal. Then again, I remember talking to some of our friends in the UK before we left and trying to convey to their confused-looking faces why on earth we’d move away from the town where we’d grown up, much less the country we live in — if you ask them, what we did would probably be an enormous thing.

The Future

After all the uncertainty and worry that it’d be a disaster, we’ve only been here for twelve months and I think we’re here to stay. Between my fiancé and I, we have around 48 years of collective experience of living in the UK and, well, we both were kind of expecting to miss the UK at least a bit. Personally, I miss a few of my friends but otherwise wouldn’t care if I never set foot in the country again. My fiancé is the same, albeit also having a tightly-knit family in the UK. Sweden is by no means perfect, but we seem to get on with the Swedish way of living much more than the UK way.

It doesn’t hurt, of course, that Sweden is beautiful. Of course, the UK is beautiful in places too, but the following snapshots were taken within 30km of the capital city. Try that around London!

I’ve always known that Stockholm is small compared to London. I mean, the population of Greater London is more than 80% of the population of the entire of Sweden. However, I didn’t really realise how small it is until I compared these two pictures I took. Obviously they’re not idea (visibility is greater in the Stockholm photo), but the London urban sprawl does on for as far as the eye can see!

I still stand by the points made in that post, and the people mentioned above seemed to think that I hated the whole app - which is untrue. I still don’t really like many parts of the UI, but it’s still a beautiful reading experience provided you memorise what all the unlabelled buttons do.

Go buy it — I did!

For a moment, I was very unnerved. I don’t like the idea of my location being stored in that much detail for so long. However, after actually looking at my data (I know, right?) I’m not so outraged, but it’s still pretty bad!

My conclusions based on cursory observation

• The data is recording the locations of the cell towers, not yours.
• If you don’t have a data connection, locations aren’t calculated.
• Cell information isn’t saved and locations calculated once you have data again.

A theory on wildly inaccurate results

Figure 2, below, shows locations in Sweden I’ve never been anywhere near in my life - mainly the ones down the west coast and southeast coast away from the big clumps.

I once visited a hotel with free WiFi. My iPad, only having WiFi to base its location on, put my position smack on a Travelodge hundreds of mies away. Turns out the base station used was moved from that Travelodge and the location never updated.

I wonder if the same happens here? It doesn’t seem implausible that cell towers are moved around without having their location updated in the relevant database.

My opinion

Location data is an incredibly personal thing. Coupled with a timestamp, you can infer all sorts of things about a person, and there have been several projects that can predict the location of a person based on historical location information like this. That they seem to be collecting cell tower data as opposed to your own location makes this less bad, but Apple really need to make it crystal clear to users that they’re storing this information in cleartext all the time they’re using their phones.

I’m not against the collection of this data at all. I understand that this sort of data is recorded all the time, either on the handset in question or by the networks themselves. My beef is that this data is being saved, seemingly permanently, unencrypted and in plain view for anyone to see, without telling me. It may well be buried in the license agreement nobody reads through, but that’s not really an excuse.

Interesting parts of my location history

Figure 1: Driving through Germany. We stayed overnight down near Belgium, then drove through Germany the next day before arriving near Hamburg for another overnight stop. I had Data Roaming switched on for a while at our stopovers, and occasionally switched it on throughout the drive to check Twitter.

Figure 2: Driving through Sweden. My data is on permanently in Sweden, of course, so the are a lot more cell towers here. There’s a very interesting hole in the data towards the South, which isn’t a one-time thing — this data was collected over three separate trips through the country: one in August 2010, the other two in March 2011.

Figure 3: Sailing past England. This data is from two separate trips, both in March 2011, on a ferry from Denmark to the UK. The ferry sailed along the British coast before heading over the North Sea to Denmark.

Boy, was I born in the wrong country. I’ve been here less than 48 hours and I’m already counting the minutes before I can go home again.

This is the hardest thing in the world to describe, but England is… dull. Not boring, but the colour palette seems to be muted. I thought I was imagining things, but after chatting with a friend of mine back in Sweden today, it seems I’m not alone. We share similar theories — perhaps the significantly higher traffic levels make everything near the roads dirty, or the higher pollution levels coupled with higher rainfall covers everything in dirt, but there’s a definite difference.

I miss the clear air. The modern communications infrastructure. Being able to drive somewhere without joining a queue of traffic. The inability for anyone in Sweden to comprehend why on Earth I’d move there without a Swedish girlfriend or family member forcing me. Hell, even the damn traffic lights.

I miss home.

I don’t, however, miss the mosquitoes that’ll be waiting when it gets warmer. Little fuckers.

A few weeks ago, I gave a talk at a Stockholm Cocoaheads meeting about being an “indie” developer. Rather than talking about programming, I talked about the lifestyle and what it’s like to live under this model, eventually concluding that although it can be tough at times, the tradeoffs are very much worth it if you can stomach the pitfalls of a life without guaranteed fixed income.

You can download the slides from the talk here.

Well, I feel a bit silly now.

As of February 7th, 2010, I will no longer be an independent developer — I’m joining the great team at Spotify here in Stockholm. For the two of you on Earth who aren’t aware of Spotify, their tagline sums it up nicely: “All the music, all the time”. They run a music streaming service with the idea that you can listen to whatever you want whenever and wherever you want to. It’s a great service which I’ve been using for a long time, and I’m really excited to be able to help make it better.

I’m aware that this change is the opposite of what many think is the ideal path. The idea is to work for “the man” for a few years while slowly building up ideas and projects in your spare time, before quitting and making a break for it as an independent developer. So, why give up a successful independent software business and go work one someone else’s product?

Well, the last couple of years have been tough, for sure. However, I’ve gone through the worst and am pretty much out the other side. The main problem here is that I suck at running a business. Like, reallysuck. I hate it. I want to be coding, not dealing with payroll and VAT and corporation tax and so on.

Still, everything is looking up and I came to Sweden with the idea of carrying on with it, and possibly incorporating in Sweden down the line if we decided to stay.

Then, at the Cocoaheads meeting I mentioned above, I got chatting with a guy from Spotify and how they were looking for more developers. After a little while, we agreed to meet up at Spotify HQ for an informal chat (which I later learned was actually my first interview), after which I was invited back a second time for a “more formal” interview.

At this point, I realised that I needed to sit down and figure out what I wanted to do, since it wouldn’t be fair to go back knowing that I’d never take a position because of my indie work. So, I sat down with my fiancée and talked it out — what it’d mean for us, if we would be happy to stay in Sweden long-term, and so on. Eventually, it boiled down to one question:

In ten years, which decision could I most regret taking?

This was fairly easy. I know I have the skills to be an indie developer, even if I hate certain aspects of it. I did it once, and I can do it again. If working at Spotify turns out to be the wrong decision, I can leave and start again.

However, what if I turn down a position at Spotify? This could be the only chance I’ll ever get, and I’d never know what I missed out on.

So, I went to my “more formal” interview confident that I was interested in a position at Spotify. It went well, until they asked a very academic question that could’ve been on a computer science exam paper. I completely blanked — the question was on Complexity, and while I did it at university and have practical knowledge of implementing algorithms and optimising them, I’ve pretty much lost the ability to express the complexity of an algorithm as a function. I managed to muddle my way through, showing my working and how I’d implement the algorithm, but couldn’t answer their question.

When I left, I was crushed — surprisingly so. This told me that deep down, I really wanted to work at Spotify, but unfortunately I’d just blown it. Rather upset, I headed home, confident that I wouldn’t be hearing back. I guess the fact that I’d been discussing it so much with my fiancée, and that I’d pretty much decided I’d take the position if it was offered set me up for a big fall.

A couple of weeks later, an email arrived. Spotify wanted to bring me back for two more interviews! They wouldn’t want to tell me how much I sucked twice, would they? This must be a positive thing! The rest was history, and I start in a couple of weeks.

Q&A

What about your existing projects?

Music Rescue will continue to be available. It works just fine, and I’ll keep it that way. The in-progress major rewrite will be scrapped, and in the next week or so I’ll release an update (version 4.2) that’ll bring some of the completed under-the-hood changes planned for version 5.0, including a rewritten (faster!) copy engine, simplified licensing, playlist folders, etc.

Clarus will continue in my spare time as a labour of love.

Teleport: AddOns will be finished, released and will continue in my spare time as a labour of love. It’ll also be free. Hooray!

Open Source and Minor Projects will continue to exist but only worked on in my spare time.

So, wait, does that mean you’ll be staying in Sweden forever?

Who knows what the future will bring? For now, though, yes.

So my friend and I started this awesome band. We’re gonna be the next, like, JLS, you know? JLS but ironic. Can you get us on Spotify?

Sure! Go here.

Can you get me free stuff/subscriptions?

I think I have a couple of Spotify stickers somewhere. Other than that, unfortunately not.

OMG YOU SELLOUT!

That isn’t a question, but yes.

You’re really going to stay in Sweden? It’s SO COLD.

Sweden is awesome. In fact, before I even learned that Spotify needed developers, I was looking for reasons to stay longer than 18 months. It isn’t as expensive to live here as I was led to believe, either.

While I’m serious about my virtual racing, I don’t see the point in spending ridiculous amount of money on a mount — my steering wheel is mounted on a 199kr/£15/$18 height-adjustable desk called DAVE from Ikea. Unfortunately, the desk is far too light to be used without modification — the force feedback is powerful enough to cause the desk to kick away from underneath you when you’re gripping the wheel. Fortunately, there’s a very simple modification you can do to the desk to stop this from happening.

The solution I used is to attach the pedal box to the base of the desk, allowing the weight placed on it by your feet to keep the desk steady. This is nice and simple — the screw holes in the bottom of the pedal box line up nicely with the “arms” of the desk’s base — simply screw a couple of screws into the base at the correct places, hook on the pedal box, and you’re good to go!

Another problem with the DAVE desk is that its feet are hard plastic, which aren’t grippy on anything. Depending on your floor’s surface, you’ll need either some sticky rubber feet or some carpet spikes to keep it from sliding away from you while you’re driving. It’s also worth noting that you get a vertical driving position with this desk — you’ll need a fairly high chair (i.e., probably not your sofa) to use this without doing your back in. If you’d prefer a more horizontal position (in that the pedals are more in front of you than below), this isn’t the solution for you!

Update: I’ve found that you can get a much more natural driving position if you cut off a single guide pin and put the desk top on backwards — the pedal box then hooks to the base at the front rather than the back. This is much closer to the driving position in a typical car than if you put the desk together “correctly”. Picture at the bottom of the post.

I’ve seen a few solutions to this from different developers, and the most prominent ones seem to be:

Sell your application on the App Store store at normal price while continuing to distribute bugfix updates to existing users as before

This is what I do, and it’s the best of both worlds. Existing customers get updates and I get new customers through the App Store.

Go App Store only for sales and refund existing customers if they’d like to buy your application again on the App Store

This is how Realmac are dealing with the transition for their Courier application.

Go App Store only for sales, rewarding people who opt to purchase again with genuine added value

An excellent example of this is how Pixelmator is being transitioned — they’ve temporarily discounted Pixelmator greatly and announced that it’s going to be App Store only in the future. If users want to switch, they can’t get a refund but they can buy it again for cheap, with the promise of a free upgrade to version 2.0 when it ships.

Since Pixelmator has been out for quite a long time, they’re essentially letting users pre-order 2.0 on the App Store. However, right at the end:

P.S. Even if you decide not to move to the Mac App Store we will continue to provide free Pixelmator 1.X updates til version 2.0.

So, I get free updates to my current version and 2.0 for cheap? Sign me up!

Both of these solutions are great, as they treat customers and their money with respect. However, a fairly high-profile catastrophe happened with a little application called CoverSutra. Their policy is:

Go App Store only, give existing customers no refunds and if they want to receive any further updates, they have to buy the application again

You can read the first explanation here, along with a followup to the backlash here. People are pissed, and it strikes me that the application’s author misunderstands why people are pissed.

In my Twitter stream I’ve seen a fair amount of discussion on this, and a lot of people defending the decision with things like:

• $5 isn’t a lot of money! If they like the application enough, they should be happy to pay again.
• I never expect free updates to any piece of software I buy.
• That was a hard to keep promise, so it’s OK that it’s been broken.
• It’s only a little piece of software, why are people getting so pissed about $5? Surely they’ve got more important things to be worried about?

All of those defences may be true. And don’t call me Shirley. However, let me state a fact about software distribution, especially amongst indie developers. I will stake my reputation on this being true.

The policy to give free updates to a purchased major version of a piece of software is so commonplace, if that’s not what you do then you need to either state that explicitly at purchase time or, preferably, rethink that policy.

I’m an application developer and I’ve never expected anything less from a software purchase. If I buy version 1.x of an application, I expect to get all the updates to 1.x for free, but then pay for 2.0. It’s how everything I own works, and how I operate my own software. What if the 1.0 I buy only ever stays at 1.0 and I don’t get any updates? Fine. What if the updates are only bug fixes? Fine!

So, having the update to CoverSutra 2.5 from version 2.2.2 be paid? Big no-no. However, this implicit expectation of free updates was explicitly backed up with this:

Trust takes an age of good deeds to build, but only one misdeed to shatter instantly

I bought CoverSutra, trusting that I’d get free updates as promised. My trust was broken, and even though it’s over something as stupid as updates to a cheap little application, it makes me feel like an idiot for trusting in the first place. People don’t like being made to feel like idiots!

No, $5 isn’t much. Yes, things change, and you perhaps shouldn’t promise things you’re not sure you can deliver. Perhaps users shouldn’t expect free updates unless you promise them.

Tough. That’s not how customers think.

If you promise free updates until version 3, give them. Even if you don’t promise? Give them. If moving to the App Store and keeping a non-App Store distribution of your application going at the same time is too hard*, don’t. Either be smarter about dealing with it, or wait until you have a major upgrade to distribute.

That’s why people were pissed at Sophiestication to start with. Everything that followed — talking down at her customers, etc, just made things worse.

Developers - Disagree At Your Peril

Honestly? If you’re an application developer and you disagree with me, then fine. However, I’d be willing to bet that you’re also disagreeing with the vast majority of your customers, which is less fine. They give you money, and you probably need that money to live. Even if you don’t? They give you money. When someone gives me money, I damn sure try to keep them happy, because I expect nothing less of people I give money to.

* I personally think the argument that keeping two distributions going is too hard is BS, and is just the developer being lazy. I do it, and it’s not hard or time consuming at all.

For example, to the left you can see Clarus version 1.5.4 (239), which is the version you can download from my website. The version submitted to the Mac App Store is 1.5.4 (247) for a couple of reasons:

• If you’re distributing apps both in and out of the App Store, you want the human-readable version number to be the same in both so users don’t feel the version in the App Store (or not) is “newer” than their version.
• It’s handy for easily identifying App Store copies of your app with a simple “What version do you have?” question, just in case the App Store build has a unique issue.
• The only changes between the builds are App Store related - no functionality changes at all.

This build number is inserted into the CFBundleVersion key in the application’s Info.plist automatically by a build script. It’s based on a script by Martin Pilkington that does a similar thing for the Bazaar VCS, but with a few differences:

• It uses Mercurial rather than Bazaar.
• It doesn’t use the presence of a .hg directory to determine whether the project is under version control or not, since this breaks if your Xcode project isn’t at the root level of the repository.

And, most importantly in my eyes:

• It modifies the Info.plist file inside the built application rather than the one in your project. This minor difference means you don’t get an unclean repository by building the application.

To use the script, right-click your Target in Xcode and choose Add > New Build Phase > New Run Script Build Phase. Set the new script to use the /usr/bin/perl shell, and paste in the script below. Enjoy!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#Check if we're versioned under hg
my $revno = `/usr/local/bin/hg id -n`;

if ($revno && $revno !~ m/abort/i) {

  print("Revision number is " . $revno);

    #get the revno minus the new line
    $revno =~ tr/+//d;
    substr($revno, -1, 1, "");
    #open the info plist
    open(my $input,  "< ",  "$ENV{BUILT_PRODUCTS_DIR}/$ENV{INFOPLIST_PATH}")  or die "Can't open Info.plist: $!";
    my $outputstring = "";

    #loop through each line until we find CFBundleVersion, then substitute the next line
    while (+<$input>) {
        $outputstring .= "$_";
        if (/[\t ]+<key>CFBundleVersion< \/key>\n/) {
            my $line = +< $input>;
            $line =~ s/([\t ]+<string>)(.*?)(< \/string>)/$1.($revno).$3/eg;
            $outputstring .= $line;
        }
    }

    #write back out to Info.plist
    open(my $output,  ">",  "$ENV{BUILT_PRODUCTS_DIR}/$ENV{INFOPLIST_PATH}")  or die "Can't open Info.plist: $!";
    print $output $outputstring;
} else {
    print "This project is not versioned";
}

Me too!

That’s why I’ve come up with a revolutionary new product — the iPod Transporter!

Using the iPod Transporter, you can store and transport your iPods and iPhones in speed and style!

Features

Equipped for Speed and Style

iPod Transporter is outfitted with two motors, for unrivalled power and speed! In addition, the tracks are independently operated allowing iPod Transporter to turn a full circle on the spot!

Built for Stability and Versatility

Unlike other Lego-based iPod storage and transport solutions on the market, the iPod Transporter has its battery pack and motors as low as possible in the chassis, giving great stability during those high-speed turns — and the tracks allow it to traverse rough terrain with ease!

Built-In iPod Dock and Cable Management

Sick and tired of losing your iPod cables and docks? With its built-in Universal Dock, iPod Transporter makes that problem a thing of the past. Simply drive your iPod Transporter up to the computer of choice, plug it into a spare USB port and place your chosen device into the built-in Dock.

Remote Controlled

No longer do you have to, um, manually drive your iPods around! iPod Transporter comes with remote-control functionality as standard!

Shuffle Pouch

No longer will you lose those tiny iPod Shuffles down the back of the sofa! iPod Transporter is equipped with an innovative storage solution for your iPod Shuffles — and even the Sixth Generation iPod Nano. Simply extend the pouch, place your iPods inside and safely stow it away again.

Don’t delay, get yours today!

Disclaimer

This isn’t a real product. If you want to build one yourself, you’re on your own! However, mine was built pretty much exclusively built with parts from the Lego Motorised Bulldozer.

With the announcement of the Mac App Store, one framework has been causing lots of trouble for a lot of people: Sparkle. Sparkle is a framework that implements automatic updating, and is awesome — therefore, everyone uses it. However, it directly violates the App Store rule stating that you’re not allowed to do your own updating. I made a new build configuration that defined an “App Store build” build variable, then had the App Store build hide those parts of the UI from users and disable Sparkle’s checking. Unfortunately, this wasn’t enough!

The trick for this isn’t to remove Sparkle from the App Store build — it’s to add Sparkle to the non-App Store build. The problem here isn’t the framework itself — simply create a new Target for your application that doesn’t include it. More tricky is managing UI — to do this, I made a little helper class to keep things simple for my applications that may want to use Sparkle and have a separate version for the App Store.

My technique moves all of the application’s self-updating UI into a separate nib file, which is controlled by my helper class, a subclass of NSViewController:

As for the helper class, allow me to present the simplest sample code ever:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#import "SparkleHelper.h"

static NSString * const kSparkleHelperNibName = @"SparkleHelper";
static NSString * const kSparkleUpdaterClassName = @"SUUpdater";

@implementation SparkleHelper

-(id)init {

    if (NSClassFromString(kSparkleUpdaterClassName) == nil) {
        [self release];
        return nil;
    }

    if ((self = [super initWithNibName:kSparkleHelperNibName bundle:nil])) {
        [self view];
    }
    return self;
}

-(NSMenuItem *)checkForUpdatesMenuItem {
    return checkForUpdatesMenuItem;
}

@end

All this does is check if the SUUpdater class, used by Sparkle, exists. If it does, it loads the nib file containing my “Check for Updates…” menu item into an IBOutlet and the chunk of UI to be placed into the Preferences window into the view controller’s view property. Below is code copied and pasted from Clarus itself — applicationMenu is an IBOutlet to the Application menu, and updatesView is an IBOutlet to a view in the Preferences window that should contain the self-updating UI.

1
2
3
4
5
6
7
8
9
10
11

SparkleHelper *helper = [[SparkleHelper alloc] init];

if (helper != nil) {

    [applicationMenu insertItem:[helper checkForUpdatesMenuItem] atIndex:1];
    [applicationMenu insertItem:[NSMenuItem separatorItem] atIndex:1];

    [updatesView addSubview:[helper view]];

    [helper release];
}

This technique will avoid having to use compile-time #ifdefs to change the behaviour of the application. Simply create a target that doesn’t include the Sparkle framework and the little helper class will do the rest. This is an incredibly simple technique, but it saves a fair amount of effort if you ever have to do this more than once.

Example 2: Supporting Multiple OS Versions Using Bundles

We’ve all had it. A new operating system version comes out, and we’d really love to support X or Y new user feature in our applications. However, what about our customers on older systems? Depending on your userbase and attitude, this might not be an issue. However, if you’ve a really large userbase, even the 5% or whatever who are still on Mac OS X makes up a large number of people I’d like to keep happy.

The standard technique, in Xcode at least, is to set your Base SDK to (say) Mac OS 10.6, and your Deployment Target to (say) Mac OS 10.4. That way, your app will run on 10.4 but the compiler will let you write code for 10.6 as long as you’re careful about what you use when.

Personally, I’ve never been a huge fan of this approach. It works absolutely fine, but you’re pretty much on your own on when it comes to defending against calling a new API on an older OS version. You can do all the -respondsToSelector: and NSClassFromStrings you like, but I’m always scared I’ll miss something and crash.

Clarus uses one specific Mac OS 10.6-only feature: the Image Capture API, which provides views for viewing and importing images directly from a camera or scanner.

To achieve this, Clarus has both its Base SDK and Deployment Target to Mac OS 10.5. However, it has a separate target with Base SDKandDeployment Target set to Mac OS X 10.6, which is compiled into a bundle and embedded in the Clarus application. This allows me to have the compiler defend against using 10.6 APIs in the main application while having a place I can write 10.6 code without restrictions or checks all the time.

If you try to load this bundle in Mac OS 10.5, you’ll get a nil bundle and an error in the Console, so it’s dead easy to check for. Since spewing stuff into the user’s console is bad (I’m looking at you, Steam), you might like to put minimum/maximum OS versions in the bundle’s Info.plist and check them before attempting to load.

In code, this can then be used as needed. For example, Clarus attempts to load all the embedded bundles present, and maintains a list of these internally. When a piece of code, it can do a simple check and alter the UI as needed:

Conclusion

Neither of these techniques are new or special. However, they work very well for dealing with “optional” code in your application, which you’ll need to do if you want your application to be distributed using multiple methods, or if you want to support multiple operating system versions intelligently.