Apple Implements Annoying Fake Security

On my way home this evening I read about the Battery Health app for giving information about my MacBook battery.  Sounded like a handy thing to have so I fired up the App Store when I got home and tried to install it.  I say “tried” as no sooner had I entered my Apple ID password as I was faced with this window.

Security Info Window

“Bloody hell”, thought I, “more stupid question/answer pairs to remember.  Well at least they haven’t …. oh no.”  Yes, not only have Apple gone in for the security question theatre but they’ve also gone and implemented a fixed set of questions rather than allowing them to be personalised.  Beyond that they’ve gone for the “trendy” approach of asking non-standard questions.  No “what’s your mother’s maiden name” type questions here.  No, it has to be about your favourite teacher, car, and other such guff.  I’ve copied the options you’re allowed to select from below.

The Fixed Security Questions

Well, this is just bloody brilliant.  Possibly these questions do mean something to you and you can always pick the same answer from your mind, in which case these could be secured more easily than any password by using some social engineering or looking at Facebook.  If, on the other hand, the questions mean nothing to you (and, as I’ve mentioned before, it’s amazing how many idiots implement lists of questions that don’t apply universally) then you’re either going to get stuck every time you have to answer them or you’ll end up writing them down somewhere.  How very very secure.  Maybe you think I’m being a bit over the top in accusing Apple of providing a useless set of questions, so let me ask a simple question.  Given that one fifth of the available questions depend on car ownership, how many people in the world have never owner a car?  Now, as an alternative, how many people don’t know their mother’s maiden name?  While the standard questions one finds in these types of forms have no benefits (or indeed detriments) in terms of security level, at least they do tend to cover a wider range of people.  Better yet, why not offer completely customisable options?  Oh yes, because it’s Apple and Apple knows best.

Unfortunately Apple’s technical support have not been particularly helpful so far, only suggesting I raise a ticket for iTunes feedback.  Well, that doesn’t exactly help me install new software on my Mac or update (say to improve security) existing apps.  Oh well, once again I realise why I absolutely loathe Apple as a software maker.  Love their hardware, hate their systems, hate their policies.

For a good explanation of where this sort of authentication came from and why it’s utterly daft, head over to The Daily WTF to read about Wish-It-Was Two-Factor authentication.


Spending Time to Save Time: Automating My Builds

As a one man developer it’s very easy to fall into patterns of bad habits with the development process.  I don’t have a team to worry about, I’m not beholden to any code reviews or quality metrics and it’s just me and my PC, so why go the extra mile to do things right?  Some things have clear benefits and such a small up-front effort requirement that they’re a no brainer.  I have a svn repo running on my NAS and this has saved me many a time – do not underestimate the sinking feeling you will get when you realise the drive that just failed in your PC was the one with your dev environment on it.  Even if you don’t have a seperate server for source control, it may be worth considering a local install and then regular dumps of your repository to external storage.

OK, so that was quite an easy example.  Job done, point justified right?  Well, not quite.  I’d like to share an example of another area where a little bit of upfront effort has made my life easier: automation in the build process.  Now, to be clear, I’m not talking about a full end to end build process / CI here.  At the moment I don’t see the value in that beyond providing me with an excuse to spend money on a server.  Any changes I’m making in code I’ll be immediately deploying to either a simulator or device depending on my current requirement.  There is, however, one key part of my build process that needed some automation and that’s creating art resources.

I’ve written before about the tools I use to create sprites: Inkscape, Blender and TexturePacker Pro (with a splash of Paint.NET) all come together nicely as a toolbox for those who aren’t up to creating graphics by hand.  The thing is, when I want to tweak a sprite, change something completely, add something new or provide assets for multiple resolutions I have to go through a hell of a process to manually deploy this to a build.  Let’s take creating a new menu button as an example:

  1. Create the menu button in Inkscape
  2. Save this somewhere sensible that I’ll find again later
  3. Export the region I want at a scale for the app sizes I want (1080p, 720p, SD, etc.)
  4. Store these exported files somewhere
  5. Open up the texture atlas definitions for each app size and add the new assets
  6. Export the new texture atlases and their indexes and save these somewhere
  7. Copy the new atlases into each project that uses them and rebuild

The process doesn’t differ much for making small changes to existing sprites.  As you can imagine, this results in me looking at to-do items demanding I perform a bit of an art clean-up, sighing and then ignoring them in favour of playing with some new code.  Not a great position to be in. Looking at the above process, there’s clearly a lot of scope for automation and process improvement.  I’ve probably made a lot of things more difficult than they need to be as this was my first project.  Luckily, all of the apps I use come with command line functionality that provides what I need to make my life easier.  By making a few design decisions I now have a three step process:

  1. Create / edit Inkscape / Blender files
  2. Run batch script
  3. Rebuild apps

Nice eh?  To do this I’ve set up my environment in the following way:

  • All projects now look for texture atlases in a root project folder called Resource[X]\textures where the [X] is a number indicating whether the resources are HD or not
  • All Inkscape / Blender files are designed with the assumption of a HD screen to display on and placed in a Textures path within the project directory
  • Sub directories within the Textures path group the texture source files together by theme (uicontrols, menus, decorations)

The batch script (Windows version attached) iterates over each sub-directory and uses Inkscape and Blender to output full resolution PNG exports of each file to a temporary directory, divided up with the same sub-folder structure.  TexturePacker Pro is then used to create an atlas from each of these sub-directories.  This is run three times as TexturePacker Pro will handle reducing the size of the atlases for the different resource sets (I use three multipliers – 1, 0.7 and 0.5).  All that is then left in code is to import the atlases and refer to the textures within by name.  While the process could certainly be made more efficient (by not re-working items with no changes), this isn’t necessary for my personal needs.

If you want to look at the details of the arguments I use on the command line, grab the batch script and take a read.  It’s not amazingly complicated but the effort required to create it more than pays for itself.

The script: generate_svg_to_png


Blackberry PlayBook Development: First Impressions

I should open with a summary. My first impressions of developing for the PlayBook have been very good overall. In the past I believe RIM haven’t made things that easy for many developers to get started on their platforms. My account was originally registered in 2009 when I used to own a BB, but I quickly gave up when faced with requirements to get notarised ID, etc. etc. Some of these problems apparently existed earlier in the PlayBook’s life as well but RIM has taken note and clearly been working to make things better, but there are still some opportunities for improvement. I’ll tackle my first impressions with getting set up to develop for the PlayBook by theme: registration, tooling up, development, support and publication. With all of these I’ll try not to dwell on timelines too much – there has been a massive influx of developers and apps thanks to the PlayBook giveaway and it sounds like RIM have been swamped dealing with this.

Initial sign up as a vendor for the BlackBerry App World is a fairly simple web based affair with few pitfalls. As an independent developer you will be asked whether or not you will be charging for apps. I believe this can be changed later. If you do opt to put apps up for sale then you will not have your vendor account activated immediately. You will be sent an e-mail requesting proof of ID and this is then reviewed by the App World team. In my case this was turned aroundin a couple of working days and they were happy to accept scans of my UK driving license as proof of ID and address. This is a big improvement over my experiences of a few years ago where more expensive options involving notaries were involved. There’s also no charge to register as a vendor these days, which is certainly competitive given the Play Store $25 up front and Apple’s annual $99 fee.

There’s not a lot of room for improvement here. Two small things spring to mind:
1. The generic ID requests aren’t very helpful. There needs to be more details of what is acceptable, especially for international vendors.
2. I now have seperate accounts for the vendor portal, the forums and the BB Jam Zone. Wouldn’t it make more sense to do this as single sign on, possibly linked to the BlackBerry ID.

Tooling Up
There’s quite a range of platforms available for development on the PlayBook: C++, HTML5, AIR, Android. The choice for each developer is likely to come down to where they may have existing components to re-use and any cross-platform considerations. Personally I went for the C++ native SDK route and my choice was driven by wanting to use a particular framework (cocos2d-x).
All of the tools you need are freely available on the BlackBerry Developer site and you don’t need to register to download these so you can have a play with them before you commit to the world of RIM. Along with the development environments / eclipse plugins offered, there is also a PlayBook simulator. This runs on VMWare Player in Windows or VMWare Fusion on a Mac. For native SDK development, the QNX IDE (built on Eclipse) is a nice clean tool and integrates well with the simulator running in the VM.
Getting my hands on the tools was one experience where there is definite room for improvement. I’ve got the following gripes I’d like to see disappear over time:
1. You want me to download how much?!? These things are absolutely massive. Additionally I can’t see any updating path that doesn’t require a full re-install (certainly updating both the ndk and simulator from the beta required a full update). This is quite a fail IMHO – take a lesson from Android’s SDK manager, not Apple’s delivery of an installer through the App Store.
2. Do not try to force a downloader plugin on me. I like my browser how it is thanks. I have to reject the install before I’m even offered a direct link. In all honesty, I wouldn’t have minded so much except when I first tried the downloader plugin it downloaded everything and then kept delivering broken installs. Avoid like the plague.
3. VMWare Player is fine. It’s free and only requires an irritating registration with VMWare. VMWare Fusion, however, is a retail product – I like to develop on my Macbook Air when I’m on the move so this has basically forced me to outlay thirty quid to keep my simulator running. Bravo RIM, bravo.

RIM have provided a few examples to get you kicked off on the dev side. These are helpful, but what is even better is that RIM really seem to have embraced bringing Open Source components into their platform. There’s a whole page dedicated to open source components that have been tested with the PlayBook. This is especially handy for game development – no need to ween yourself off Box2D!
Documentation is present, but I found it rather hard to navigate. In my opinion it could do with a bit of work on the layout of the docs. There are a few too many pages that don’t provide enough cross linking to help you dig into further detail, instead just leaving you in loops where pages link back to each other. I have more than enough of that using HMRC’s website.
All in all I can’t complain about developing for the PlayBook. I didn’t run into any real problems beyond the standard PITA of setting up environment variables on OS X. Only one improvement suggestion here:
1. Give me a local copy of the docs please! KTHXBYE.

Support for developers by RIM has blown me away. Even ignoring the idea of pushing devices out to people as a reward for publishing an app, I’ve seen a great level of support in the few weeks during which I was getting Flip! migrated.
The Developer Support Forums have some genuinely useful people on as well as BlackBerry personnel chipping in with helpful answers. There’s also a good BB dev presence on Twitter and their Blog. I’ve been impressed with the level of engagement from people like Alec Saunders and Alex Kinsella as well.
The only issue I have is that their forums are a little clunky and aren’t always easy to search or navigate. I’d really like to see a community wiki growing at some point as this would help flesh out any gaps in the documentation.

Publishing to the App World is done through the vendor portal. The portal allows you to maintain your application descriptions, prices, screenshots and releases. It also provides facilities to set up test “sandbox” account to test purchases without having to make an actual payment.
All releases to go onto the App World go through a review and testing process. Much like Apple’s offering, there doesn’t appear to be a lot of transparency around exactly what goes on in this process. From anecdotal evidence on the BB Dev forums, this lack of transparency extends to rejection feedback, which may irritate many developers. I haven’t experienced this personally so I won’t say any more. The review SLA is 7-10 days, and by all accounts they are able to hit this (outside of free PlayBook madness periods). On releasing an update with minor changes, the review turnaround seemed even quicker so I can only guess that the update reviews are a lighter version of the initial approval.
Once in the App World, I could easily search for the name of my app and find it (you hear that Google?). Unfortunately there’re a couple of issues with the App World. For one, the screenshots seem to be getting massively downscaled at the moment so appear very pixellated. The second problem for me was that the RIM view of links to the App World seem to be all about going to single apps rather than vendors. The web portal for the App World does offer a way to view all apps by a vendor, but the PlayBook itself (and so the calls you can make in the native SDK) does not. This seems really odd to me as it seems a no brainer to allow publishers to present links saying “hey, did you like this? Have a look at our other stuff then!”
The one other problem I have with the App World over the Play Store is that I have to use my real name as an individual. I don’t exactly go to great lengths to hide my identity on the internet, but in this case I like to put everything under “floor4”, something I’m not able to do here without registering a name to trade under. I understand, however, that this is a very personal gripe so I can’t really hold this against RIM.

So my overall experience with developing for the PlayBook has been good. There are certainly improvements to the process that could be made, but I’ve never seen a process that couldn’t do with tweaking and RIM certainly seem to be trying to introduce more and more improvements. At the end of the day, it’s another market and well worth your time to investigate. With BB OS10 around the corner you never know, RIM may just get back in the game and make us think of the top three of the mobile world rather than just the two (oh … and WP7 I suppose …).


Development Update – February

Another gap in posting, but a productive one. In January I was investigating some cross platform Lua based frameworks (Moai and Gideros) but between a skiing holiday and recovering from injuries sustained while on a skiing holiday I didn’t get beyond a few proof of concepts. Both are worth a look, and I’ll probably return to them in the future, but my investigations were derailed by this post on the Inside Blackberry Developer’s Blog.

So, with PlayBook OS 2.0 comes (limited) Android support and RIM were offering PlayBooks to developers who submitted apps within a timeframe. Hard to resist really (and it’ll be interesting to see how this pays off). As I have no willpower I went ahead and signed up, hoping to easily repackage Flip! for the PlayBook. I ran into immediate problems as (among other things) native code in Android apps is not yet supported, but this provided me with an opportunity to pick up one of my other to-do list items and learn to use cocos2d-x along with relearning C++ so I could re-build Flip! using the BB Native SDK. I’ve now completed this and just had the app approved on the App World! I eagerly await my new shiny shiny and will tell all about it when it arrives.

I’ll get a post up this weekend about the process of signing up for PlayBook development and my first impressions.


CPU Wars Volume 1.0

I buy a lot of random geeky stuff (evidence: the second copy of Aliens vs Predator for PS3 I bought only so I could get another plastic facehugger), but one of my geekiest recent investments has to be CPU Wars Volume 1.0, and I couldn’t be happier. CPU Wars is the brainchild of Harry Mylonadis and his project has just come to fruition after successful Kickstarter funding. CPU wars is a top trumps game featuring the specs of thirty different CPUs. Ever had an argument with a friend about whether the Phenom II is better than the Core i5? No, neither have I, but now you can and the result can be decisive (SPOILER ALERT: the Phenom II is inferior in all but one category)! Anyway, head over to to check out more on the history and future of CPU Wars and to pick yourself up a deck or two.

Master Chief Looks Up The Specs For 343 Guilty Spark


Yet Again OS X Pokes Me In The Eye (or OS X Environment Variables)

I bought myself a Macbook Air last year to replace my ageing laptop. The theory was that I’d be using cross platform apps so the underlying system didn’t matter. Or rather it didn’t matter enough to outweigh the pretty 🙂

Anyway, not all of the niggles I have are down to OS X (Apple’s “we must have our own way” GB keyboard is bloody awful and seems designed to piss off developers), but many are and I’ve just come across another. Trying to set consistent environment variables across all apps, regardless of whether terminal based or launched from an icon is an absolute mess. Worse still, Apple doesn’t seem to offer any standard friendly configuration methods for environment variables. Pricks. Anyway, the best resource for troubleshooting these that I’ve found recently is this post on stackoverflow. I’ve reproduced it below in order to ensure it is captured and kept!

There are several places where you can set environment variables.

  • ~/.profile: use this for variables you want to set in all programs launched from the terminal (note that, unlike on Linux, all shells opened in are login shells).
  • ~/.bashrc: this is invoked for shells which are not login shells. Use this for aliases and other things which need to be redefined in subshells, not for environment variables that are inherited.
  • /etc/profile: this is loaded before ~/.profile, but is otherwise equivalent. Use it when you want the variable to apply to terminal programs launched by all users on the machine (assuming they use bash).
  • ~/.MacOSX/environment.plist: this is read by loginwindow on login. It applies to all applications, including GUI ones, except those launched by Spotlight in 10.5 (not 10.6). It requires you to logout and login again for changes to take effect. There is no reason to use this one any more.
  • ~/.launchd.conf: this is read by launchd when the user logs in. It applies to all programs launched by the user, GUI and CLI, on 10.5 and 10.6. Additionally, you can apply changes at any time by piping this file into launchctl (maybe grep ^setenv first if you have other commands you don’t want to run). Then the new variables apply to any application launched by launchd from that point on. This means you should restart for the new variables to cascade down into the shells it launches.
  • /etc/launchd.conf: this is read by launchd when the system starts up and when a user logs in. They affect every single process on the system, because launchd is the root process. Again, to apply changes to the running root launchd you can pipe the commands into sudo launchctl.

The fundamental things to understand are:

  • environment variables are inherited by a process’s children at the time they are forked.
  • the root process is a launchd instance, and there is also a separate launchd instance per user session.
  • launchd allows you to change its current environment variables using launchctl; the updated variables are then inherited by all new processes it forks from then on.

Sample setting an environment variable with launchd and storing it into your personal config so it works for your login even after your reboot:

echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE >> ~/.launchd.conf

Now, launch your GUI app that uses the variable, and voila!


Goal achieved?

I set myself a couple of goals over Christmas to get some Android development done and migrate this blog onto a new host. So, how did I do? The answer is: better than I expected. Migration done, some code written up (no new release though as I want to put a bit more in).
I’ve also set up a new blog that I’ll be writing about once it’s ready for public consumption. This blog is for a friend of mine who is running from John o’Groats to Lands End this year to raise money for the Royal British Legion (a charity for those who are serving and have served). That’s over 30 marathons in a row! This chap is insane, but insane with a big heart.
Anyhow, am currently in a taxi to the airport as am of skiing for a week so will provide an update on my return.



I’m currently in the process of migrating hosts to the wonderful people at Arvixe.  I’ve been very impressed with their pre-sales and initial tech support so far so let’s hope it continues!  Right, back to sorting out my e-mail ….


A brief update

Q4 of 2011 has been somewhat hectic for me and so I’ve put no time into any Android development.  Little drabs of time are getting thrown into forums & comments here and there, but nothing productive.  I’ve also totally screwed the images on this site so am in the process of sorting that out.  As there’s a three day weekend coming up (and allowing for a massive 1st January hangover), I’m going to dedicate a few hours on Saturday and Monday to:

– Updating Flip! with some feedback received over at the Making Money With Android forums

– Getting some code written up for some of my parked ideas

– Sorting out this blog

I’d give myself a 75% chance of actually getting round to this!


libgdx 0.9.2

At the moment I’m playing around with some different frameworks for game development, but I’m almost certain that (for Android anyway) I’ll keep returning to libgdx.  Love the way it’s designed and the ability to easily throw my game into a desktop version for quick testing is the major strength.

The 0.9.2 update has made me even more likely to stay with libgdx after reading this:

Fancy schmancy AssetManager. I haven’t talked about it yet on here but will do so sometime next week, telling you how to use it. It’s incredibly powerful and allows for asynchronous loading of assets. See
AssetManagerTest for a taste of what it is capable of.

Now I can ditch the crappy one I wrote for Flip! …