Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery - Skyline by Tom Royal on Flickr
Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery by Tom Royal on Flickr
Old Truman Brewery 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.

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.

Stuff the App Store needs to do..

March 23rd, 2013

The iOS App Store really is a brilliant thing. I first learned to program way before internet access was widely available, so the options for sharing my first creations (in STOS Basic, on the Atari ST), amounted to 3.5in floppy disks – today, if you can code something you can easily distribute it to a global audience of millions. It. Is. Brilliant.

But let’s not pretend that the whole affair is flawless. Over the past year or two of working with apps I’ve been mentally compiling a wishlist of ‘Stuff the App Store really, really should do better’ – I don’t expect Apple to care, but since I’m waiting for a 6GB file to download over domestic broadband, here it is. If nothing else, it could be interesting to look back in another two years and see which, if any, have changed.

Free with In-App-Purchases

The whole reason this list popped back into my head today is the news that, finally, Apple seems to be making small inroads to fixing this long time issue. Many developers – my company, and my personal business, included – make use of a model where a free app can be used to offer paid-for content. My work is making magazine apps where the reader, and some articles, are free but others are paid for. My personal apps offer a limited amount of function for free, with a payment unlocking more.

Neither are entirely free, and I’d never claim otherwise, but the App Store marks them with a big ‘Free’ button, and that annoys some customers who feel they are being misled. It’s bad for them, bad for us (ONE STAR), and not exactly beneficial for Apple. It seems that the company is now marking these apps with a note on the web store view – I really hope it can find a way (‘Free App’?) to do so in the main store.

Sort out International Subscriptions

The Subscription concept used in Apple’s Newsstand is, well, odd. For one there’s the fact that subscriptions are mandatory for Newsstand, and the ‘Mandatory Free Subscription’ concept that allows free-issue publishers to work around that. But more importantly, the in-app subscriptions do not support geography.

By way of example: say I sell a magazine called Unicorns Monthly. People in, say, Narnia buy auto-renewing subscriptions. I then have to remove the app from sale in Narnia (legal letter from an angry lion) – a process Apple makes very simple. What I can’t do is stop the in-app subscriptions of my customers there, so they will continue to be billed. They’ll keep getting issues for a while, but if a mandatory update is needed it’ll be unavialable to them, and they are left with recurring payments for a product they can’t use.

It’s bonkers. If an app binary is no longer for sale in a given territory, why not make the IAP subscriptions off-sale in that area, too – that would allow app publishers to wind down support properly.

Buy, buy, sell, sell

Here’s a big one: you can’t move any app from one account to another if the publisher is bought or sold. This isn’t just a magazine thing, but it becomes an even bigger pain in the backside when the apps have subscriptions attached. My team produced four magazine apps with significant readerships – when we set up as an independent company, there was no way to take those apps with us.

The best you can do is set up a new app and close the old one, but then there are hundreds or thousands of customers – many of whom you may not even be able to contact, because Apple subscribers have to opt-in to share even an email address – who have paid for a product that disappears. There are strategies for mitigating this problem (essentially, batch importing known users into a separate authentication service for the new app, and notifying old app users of the process), but it’s a horror.

Moving apps between accounts must be a pain for Apple. But I’d pay for the service. Big companies would pay a lot.

No API for data

A minor thing, but there’s still no official API for getting app sales data – instead you can use the web interface, third party tools (I like AppViz), or set up CRON jobs to run shell scripts that use a Java autoingestion class provided by Apple (I like that too, because I’m a geek). A proper API, though, would allow for more and better analysis tools.


And here’s the big one. The current app review mechanism allows angry people to quickly lash out at a developer – sometimes with good reason, sometimes not – and, because happy customers are seldom as vocal as mad ones, pushes developers towards ‘Why not rate this app’ nag screens in order to get positive feedback on the board. In many cases, angry reviewers could be made happy with just one sentence explaining that, yes, they *can* do what they want, by tapping button X, or whatever – but the developer has no way to contact them.

It’s a tough one to fix, of course, but here’s my two cents: developers should be able to ‘answer’ any review, positive or negative, in up to 150 characters. This response would be sent, by email, to the reviewer. After this response, the reviewer would be offered the opportunity to change their review rating. Meanwhile, when an App Store user chooses to download another app, they could be offered the chance – while waiting – to quickly star-rate their last purchases.

Sound fair?