Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Highgate Cemetery by Tom Royal on Flickr
Osaka by Tom Royal on Flickr

You're using a very old version of Internet Explorer which can't show the photos that should be in this box. Please consider upgrading to a newer version of IE or an alternative such as Firefox. Thanks.

Futzing with Swift and Cocoa

June 6th, 2014

I’ve never learned Objective C – my iOS stuff is written in Titanium (essentially Javascript, because anyone can play guita.. uh, write Javascript), and my personal tools for Mac are all scripts to run from Terminal. So the idea of a simpler language that could be used for both iOS and Mac OSX is pretty attractive to me.

Problem is, I’ve never used Xcode, or the Cocoa libraries before. But I thought I’d give it a shot. Based on a few hours of futzing around, here’s what I’ve found – my planned starting point was some button handlers, text inputs, and then some XML file manipulation.

Button Handlers

You can easily drag-and-drop a button onto the window in the Interface Builder view. To handle it, you can add a handler to AppDelegate.swift. First I imported Cocoa and Foundation:

import Cocoa

Then, inside the class AppDelegate:

@IBOutlet var window: NSWindow
@IBOutlet var testButton: NSButton

Then, after the applicationWillTerminate function, add a new function to be called on button click:

@IBAction func buttonclick1(AnyObject) {
  // do stuff
  println("button clicked")

You can then link the button to this function from the Interface Builder (it’s a control-key-and-drag job).

Text Fields and Alerts

After dragging two text fields onto the window in Interface Builder, I added IBOutlet variables for them:

@IBOutlet var text1 : NSTextField
@IBOutlet var text2 : NSTextField

It’s possible to get these – and link them up – automatically by control-dragging the text fields from the Interface Builder into the right area of your code. That done, you can then a value from one field, and put it in the other one:

var fromtextbox = text1.stringValue
text2.stringValue = fromtextbox;

It’s easy to display it in a simple alert box:

let myPopup:NSAlert = NSAlert()
myPopup.messageText = "Modal NSAlert Popup";
myPopup.informativeText = "Echo that variable: \(fromtextbox)"

Because who doesn’t love extraneous alerts. Or, if you need an OK / Cancel:

let myPopup:NSAlert = NSAlert()
myPopup.messageText = "Are you sure?";
myPopup.informativeText = "Do you really want to do that?"
if myPopup.runModal() == NSAlertFirstButtonReturn {
// yes, they're sure.

Else, handle the cancel action, etc.

A File Selector

I want to choose an XML file, in order to later manipulate it. I found that I could get a file dialog box like this:

let myFiledialog:NSOpenPanel = NSOpenPanel()
myFiledialog.allowsMultipleSelection = false
myFiledialog.canChooseDirectories = false
var chosenfile = myFiledialog.URL // holds path to selected file, if there is one

And to check that a file has been chosen:

if chosenfile {
// do something with it

Maniuplating XML

Next up is opening, reading and manipulating that XML file. Getting a local file to manipulate it is pretty easy:

let xmlurl = "/var/tmp/file.xml" // or from your file chooser
let nxmlurl:NSURL = NSURL(fileURLWithPath: xmlurl)
var xmlasstring:NSString = NSString(contentsOfURL: nxmlurl);

Once you have the XML as a string, you could feed it into a proper XML parser – but I just wanted to grab a few values, so used some string manipulation using NSRange objects. You can also bust a string that’s delineated (in my case a com.something.something GUID) into an array of values really easily:

var substrofguid:NSArray = currentguid.componentsSeparatedByString(".")

.. and then when you’re ready to write the string data back to an XML file:

var myfileman:NSFileManager = NSFileManager();
var xmldatatowrite:NSData = myeditedstring.dataUsingEncoding(NSUTF8StringEncoding)
var writethefile = myfileman.createFileAtPath("/var/tmp/file.xml", contents: xmldatatowrite, attributes: nil)

You can then check that writethefile variable to see if the operation completed properly.

QNAP Nas to Nas RSYNC – Stuck at 0%

May 29th, 2014

Something I learned, and which may be useful to someone else:

One of Apptitude’s servers is a QNAP NAS running firmware 4.0.7. Every 24 hours it runs a backup, via RSYNC (SSH encrypted) to a remote site where we have another QNAP.

Last night, the backup job glitched – no errors were logged, but it just sat uselessly at 0% for six hours. Here’s what I learned:

  • The QNAP Rsync system can only handle file paths up to 260 characters
  • It doesn’t fail gracefully if you exceed this

To find the offending files, here’s what I did (on a Mac, in my case, via Terminal):

  • cd to the Volume root
  • find . > filelist.txt
  • perl -nle ‘print if length$_>260′ filelist.txt

Or, thinking about it, you could probably do it in one command:

  • find . | perl -nle ‘print if length$_>260′

Once done, remove or rename the offending files. In my case the names were too long for the Mac to handle, even via Terminal – if that happens, SSH into the NAS and delete them there.


Kittens vs UKIP

May 24th, 2014


Per the excellent suggestion of Marina Isaac, UKitten is a Chrome Extension that replaces all images of Nigel Farage or related to UKIP with images of kittens from Tea and Kittens.

It’s available now from the Chrome Web Store.

UPDATE: Now also available for Safari – click here to download, then double-click that file to install.

In App Purchases

February 2nd, 2014

Lots of people are angry about the way that In App Purchases (IAPs) are being used in iOS games. They make three key points:

1) Many iOS games are shitty and designed primarily to require the player to buy many IAPs

2) Apple promotes many of these shitty games on its App Store storefront

3) The above damage the potential of iOS as a platform for games.

I agree with all three. But some people have gone further, suggesting that IAPs should be removed entirely.

At this point I should declare an interest. I personally make apps that use IAPs – like this one. The company I work for makes digital magazines, many of which use IAPs – like this one. If IAPs were to disappear tomorrow, my own personal bank account would be affected. I’m not unbiased here. But while attempting to keep as objective a head as is possible, I’d suggest that IAPs are very useful things. They allow a couple of key behaviours on the App Store:

1) Apps that allow people to try out the content* or function before committing to pay, and

2) Apps that serve multiple units of content over time

The alternatives in case 1 are two apps (two sets of updates, two items clogging up the store, bleh) or Google’s “try for a limited time” idea, which is comprehensively crappy, as the amount of time reasonably required varies immensely. The alternative in case 2 is to release app after app after app after app, all for the same product – no fun for the maker or user.

And I’d like to suggest a third option. When you add an IAP to the Store, you’re offered several types:

  • Consumable
  • Non-Consumable
  • Subscription (various types here)

It’s the first type – Consumable – that gets abused by lousy games. It’s the one where you pay 99c for ten coins, three gems, an extra magical bunny**, or whatever. It’s of no use whatsoever in either of the cases above, as it cannot be retrieved later (‘restored’) should the user reinstall the app – it’s a one off charge. Banning these from the Game category would immediately curtail a huge amount of lousy behaviour.

Non-Consumables and Subscriptions, I’d argue, mostly work  fine – they enable a way to unlock function or content (case 1, above) and a way to sell multiple items into a single app (case 2). Non-Consumables are particularly suited for adding extra levels etc to an existing game. A subscription could possibly be abused by a game (subscribe on a weekly basis to get some kind of extra power X that multiplies your ability to collect coins / gems / magical bunnies), so perhaps there’s a case for removing these from the Games category too, but I’m not sure people are as ready with their tap-to-buy finger when it comes to an ongoing payment.

Or another alternative to banning or removing anything: why not amend the App Store Guidelines, and enforce that amendment? Apple doesn’t shy away from prohibiting other types of content and behaviour in apps that it sells – would it be unreasonable to use the same method to prohibit crappy consumable-type behaviour in games?

I’d suggest that either presents a more reasonable option than banning all IAPs once and for all. In the meantime, might I recommend the brilliant cartridge-shaped lump of mobile-gaming-wonderful that is A Link Between Worlds? It’s a one-off purchase, no IAPs required.

* Apologies for using the c-word here, but I’m trying to be as general as possible

** Is there a game that involves magical bunnies? I’d play that game.

How To: Make a 3DS grip from an old GameCube pad

May 8th, 2013

When the 3DS was first released, I was a bit nonplussed. I mean, the 3D worked just fine, but at the European launch it cost a fortune, there were few good games, and the system was made in an inexplicable turquoisey colour. In the last few months, though, it’s all changed. There’s now a lower price (especially for the older, smaller one – just £130), better firmware, and a handful of great games: I’ve been whiling away daily commutes on Virtue’s Last Reward (visual novel, bonkers translation), Tales of the Abyss (exactly what you’d expect from any Tales game), and now Fire Emblem Awakening (addictive as hell, great translation).

But with that, a new problem: hand cramp. If you have big hands, playing the 3DS for anything longer than 30 minutes at a stretch can really begin to hurt. What it needs is a big grip like, say, a Gamecube pad.


So, here’s how to make one in about ten minutes. You’ll need an old Gamecube pad (please, not a Wavebird), a hacksaw and either a Nintendo tri-point screwdriver (for those who like to do things properly) or a power drill and glue (for me). The TLDR version: hacksaw it in half.


Step one: gut the pad. If you have the screwdriver, unscrew it carefully and remove the insides. If not, drill out all the screws and pull it apart. And voila, one empty pad.


Step two: saw the top in half. I found that cutting straight across exactly through the middle of the D pad suits my hands. Before doing anything else, look at the top (cable exit) side of the bottom half: there are some raised sections. I sanded these down a bit to flatten them off and provide a better rest for the console.



Step 3: screw, or glue, the bottom halves of the handles back into place. And that’s it. I was going to add a way to mount the console in place, but actually once you pick the thing up, the two sit quite happily together in your hands.