Apr 212012
 

Yesterday I turned thirty years of age.  Feels a hell of a lot like 29 to be honest.  Looking back at my twenties, I’m reasonably happy with my achievements.  Graduated from Oxford, wandered my way up Kilimanjaro and started a promising career in the City.  Not too shabby, but I can’t help but feel I could’ve done more with the last decade.  Unfortunately I’m both lazy and easily distracted by new projects, so this year I’ve decided to set myself some goals to try to reach by this time next year.  I’m going to see how much I can work tech into each of these to help achieve my goals.  So, to the list:

  • Drop a waist size.  Nothing like working in London to fatten you up, time to sort that out.  Should give me a good excuse to try out some fitness apps.
  • Write 3 apps.  I’ve got a backlog of ideas and I need to commit them to code.
  • Buy a house.  It’s time.
  • Finish a game backlog.  I have so many games on Steam / PS3 that I’ve never played.  I need to catch up on these so I’m going to go through one platform and clear the backlog before adding anything new.
  • Visit a country I can’t remember.  This may seem like a strange way to phrase this, but I was born in Canada and left when I was very young.  I may choose this year to return.
  • Set up a new site.  I’ve got an idea and I need to actually get it done.
  • Learn 5 new things.  Might be languages, horse riding, another instrument.  I’ll work this out as the year goes on.
  • Quit smoking.  Occasional puff is alright but they’ve been taxed to a ridiculous price in the UK.  Oh, and apparently it’s not healthy or something.
 Posted by on April 21, 2012 at 9:31 pm
Apr 182012
 

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.

 Posted by on April 18, 2012 at 7:40 pm
Apr 162012
 

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

 Posted by on April 16, 2012 at 7:16 pm
Apr 052012
 

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.

Registration
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.

Development
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
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.

Publication
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 …).

 Posted by on April 5, 2012 at 8:27 pm