Knights

Given the delightful news of Jony Ive's ennoblement, I guess we should brace ourselves for a chorus of WTFs — most originating, more than likely, from a certain errant former colony over yonder westwards — decrying as anachronistic the British honours system. But to do so is to misunderstand the very important role which Knights — and, of course, Dames — play in matters of National Security. Let me explain.

Traditionally, the role of a knight has been to act as advisor to the monarch and, during times of war, as an ad hoc general. Much like Jedi, only with a better chance of getting a table at the Ivy. There were many other duties performed as well, mostly involving Questing and rescuing princesses from eg. dragons, orges, trolls, less-attractive family members, etc.. The low number of minor royals being abducted by mythical creatures over recent years attests to what an excellent deterrent the Honours System continues to be. But while still important, these knightly duties are receiving less attention these days. For instance, during the Knight Camp training session in the Scottish Highlands which all the newly elevated must attend, only a single day is now given over to jousting (although this is still fairly intensive, covering as it does not only traditional horse-back jousting, but also jousting on motorbike — both standard and with sidecar — and while hung out of the window and / or sunroof of a wide selection of motor vehicles). The role of the modern knight is that of inspirational figurehead.

Once upon a time, a knight's place on the battlefield was right in the thick of things. This wasn't a bad thing for your average knight, since the excess cash which came with his privileged position would allow him to invest in the latest greatest kit. So while everyone else had only particularly crusty sackcloth to protect them from the business end of a bec de corbin, the knight, encased as he would have been within state-of-the-art tincannery, was free to wander about at his leisure, guisarmes and voulges bouncing off him like gentle spring rain. The advent of the professional soldier was responsible for killing off the gentlemanly sport of Amateur War. Blame ol' wart-face Cromwell. What it meant to be a knight had to change with the times.

The wars of the future won't be fought in the traditional manner. But don't go getting all excited. The wars of the future won't be fought in what we used to call CyberSpace, either. No, the wars of the future will be fought on home ground, in shopping centres, car parks and chain restaurants, against zombies or aliens — or, in one particular nightmare scenario, zombie aliens. It is these wars which your modern knight is being equipped to lead. Their role is to shape whatever ragtag group of disparate survivors they stumble upon into a unstoppable fighting machine. Imagine the scene: A church hall, sometime after dark. A handful of villagers shelter inside, while outside they can hear their former neighbours shuffling around and professing their very real desire to consume brains. A door opens. Who can it be? Only bloody Sir Michael of Caine, that's who. "Alright, lads," says he. "I know we're in a bit of a spot, but don't worry, I've got a plan." Game over for Johnny Zombie.

Seriously, Rest Of The World, when the alien motherships are hovering over our capital cities, who will you have to turn to? Politicians? Celebrities? Mouseketeers? Because we'll have Captain Picard and Gandalf.

Lexical: A Retrospective

Since it's coming to the end of the year and I'm feeling a little nostalgic, I thought I'd revisit Lexical, the first iOS code I ever snuck into the App Store. This was released back in the heady halcyon days of October 2009, and since then has been downloaded literally dozens of times.

The visual style is minimalist, inspired by Bauhaus. I like to think that it had a direct influence on the design of the Windows Phone 7 / Windows 8 Metro UI, but then I'm prone to vast delusions of grandeur. Whatever, it's probably long past due a bit of a revamp.

I originally wrote Lexical in a couple of weeks, mainly so I could experiment with Core Animation layers. This time I'll be using Cocos2D/3D for the same reason. And since I've already worked out all the tricky game logic stuff, it should take far less time.

(Why, yes, those do sound an awful lot like famous last words to me.)

Topman Generation

Another thing what I wrote: the iOS version of the Topman Generation digital magazine. "But," I imagine I hear you scoff, "surely that's just a couple of web views pointing at the magazine site?" At which point I begin to cry, wishing it was that easy. Feature creep — including the one simple little word "caching" — turned this one into a bit of a nightmare.

And don't get me started on having to work with web guys. Seriously, don't. I mean, individually they're all lovely blokes, but once they start cranking out those scripting languages of theirs... You see that big grey area in the screenshot above? That's the result of removing the page headers and footers. You'd think it would be easy enough to have the rest of the page resize to fill the window, but no. Mind you, if you saw the mess of machine-generated markup it was trying to manipulate you'd probably realise why.

And as for load times... 112 requests and 3Mb just for the main page. Sigh.

Mobile is not the Future

The future is — always has been — ubiquitous computing. Users will live among an unseen ecosystem of intelligent agents who will anticipate and respond to their every need. Mobile is important because it's a large step along the path to this future. But we're not there yet. Performance, power consumption, and connectivity have come a long way, but we're still computing through a device — we still need to carry the box in our pockets, take it out when we want to use it, look at and interact with its relatively tiny screen. Some day we'll look back on these mobile years with wonder. Apps will seem as archaic as the command line on the desktop — but maybe also as fondly thought of as the clockwork workings of a watch.

Mobile isn't the future, but, for the time being at least, it is still the now.

The iPhone 4S

I've had an iPhone 4S for a few weeks now. It's unusual for me to get a new phone this soon after its launch. I took the plunge this time mainly in order to diversify my development devices. I plan to keep my old 4 on iOS 4.3 for compatibility testing and use the 4S as my main dev device — as well as my everyday phone.

There's not really much left for me to say about the 4S which other people haven't already said. Like Marco Arment, I can't say I've really noticed much of a speed improvement. This probably says a lot about the power of the iPhone 4. Certainly on paper the 4S should be noticeably faster. I usually shy away from having the fastest device available as my day-to-day development device from a — more than likely misplaced — feeling that by not having to worry about performance I end up writing inefficient code. I guess it's hard to shake my assembly language roots.

I must admit that I haven't got much use out of Siri so far. We had fun with it — I'd love to say 'she', but over here they've made Siri a bloke — over lunch one time, but that's about it. I guess I just feel too self-conscious talking to my phone.

And the only other new stand-out feature of the 4S over the 4 is the rattle somewhere at the top of the device near the mute switch. But I'm not sure that's a standard feature.

On Creativity

I've been an Apple fanboi since back when the company was doomed. Up until the mid-90s I'd been an Atari fanboi. You can guess how big a fanboi I was by the fact it took until the mid-90s for me to finally accept that the platform was dead and that it was time to jump ship. I bet I was one of the very few people to ever own a Falcon030. While I started playing around with programming on the BBC and Spectrum, it was on the ST that I really cut my coding teeth. When I got my first Mac — a PowerMac 8200/100, since you ask — I also got Code Warrior. I made some half-hearted attempts at learning the Toolbox, but somehow it wasn't quite the same — maybe what was missing was that magic which came from knocking around at the assembly level with a single, well-known hardware platform. It wasn't until several years later and Xcode under OS X on an iBook that I really got back into programming, and then what drove me wasn't so much the technology as the community.

"Style over substance" — or something with similar connotations — has been the default insult levelled at the Mac since the beginning. Variations of it were used time and again by detractors to describe the applications available for OS X, especially during the rise of the Delicious Generation. The Mac couldn't host anything like the extensive software catalogue of Windows — especially in wake of the platform's abandonment by most of the big name companies which had previously supported it — but what it did have was a number of well-made applications from numerous small independent developers. Indie developers were craftsmen, and this was reflected in the thought, the time and effort, which went into producing their products. This was the community I wanted to join.

I never did, of course. Time and circumstance conspired against me. The challenges involved in first creating, and then marketing, a product seemed too great, and I shied away from them. And then the iPhone was released. At first, the connection between this amazing new product and the Indie community didn't exist, but eventually the SDK was released and the App Store opened — and the independent developers who had supported the Mac for all these years were there at the front of the queue.

Despite the many stories of small developers striking it rich over night, I never really imagined that I'd be able to produce a smash hit app. I knew that to do it properly I would need to work with others who would fill the gaps where my skills were lacking. The couple of apps I made were to back up my claims of being a proper grown-up developer. I made a few false starts at finding collaborators online (to my eternal shame, I managed to mess a couple of people about, as well as getting messed about — and royally screwed-over — myself), but eventually I gave in and went for one of the many suddenly flourishing iPhone developer jobs.

(I have to thank Steve Jobs, not only for creating tools which I want to use above all others available, but — most of all — for creating the environment where people will actually pay me to use them. It was almost impossible to get a job as an Objective-C programmer in the UK before the iPhone, but now — even today, a couple of years on — there is still a growing demand.)

I had hoped to join a team where I'd be part of the creative process, joining in the back-and-forth and contributing. In the main this has happened. I've worked with some excellent creative people, and — since being subsumed into the world of advertising — some excellent Creatives, but I can't shake the feeling that I've always been the junior member, there on sufferance, tolerated for their technical knowledge but otherwise to be seen but not heard. In short, that I wasn't creative like those others involved in the design process. (One colleague would constantly make comments along the lines of "…even people, like you, who aren't creative…" — they cut me every time.) Sure, I didn't have any formal creative training, but then I didn't have any formal programming training, either.

I guess that there's a broader question here: Is programming a creative endeavour? Certainly it's creative in that it is the means by which an end product is created. But how much creativity goes into that process? I realised a long time ago that as far as my creative colleagues are concerned, the answer is none — that all I do is basically typing maths. (In a particularly grim low moment I changed my job description on the office intranet to read "Typist".) I'd argue against this. While programming is ultimately a form of engineering (although this is mostly an American affectation, nerds who sit in chairs all days wanting to be classed with the guys who get to wear hardhats and build bridges), that doesn't mean that it is rigid and inflexible. The skill — the craft — comes from choosing the best, most elegant solution to the problem at hand. If not an artist, I am, at least, an artisan.

I got into a minor Twitter tiff with superstar designer Sarah Parmeter at Update Conf. As part of her presentation she told a story about talking to developer friends about what the iPhone could and couldn't do in terms of sending SMS messages, and suggested as one of her top tips that designers should find out about device capabilities. I expressed surprise on the back channel that any designer should need to be told this. But, looking back, I shouldn't have been surprised at all. Too many people involved in the design of apps seem to see discovering the abilities — and, more importantly, limitations — of the devices they're designing for as some kind of check on their creative freedom. (To be fair, at the moment this seems to be more prevalent among the ranks of mangers who now seem to be charged with designing apps — wire framing, as if this were some unimportant step in the design process — than with any of the actual big-"d" Designers I work with.) This strikes me as being akin to a sculptor not being interested in discovering the various contrasting properties of marble, brass and wood. And it casts the developer, who has to step in and say no, this can't be done, in the role of killjoy naysayer.

(And we now reach the point where clients are unwilling to pay for app design time, so could we put everything that their web designers need to know about designing for apps down in an email, thanks very much…)

Anyway. Sorry. Another unfocused rant. Tomorrow I hand in my notice. After than I contract for a while. And after that — if the comfort of contracting money and the fear of failure don't get the better of me, which there's a very good chance they will — I'll start up a development shop of my own. Maybe I'll be able to convince some of my Creative friends to come and join me. But I have some strong ideas of my own about app design, and I'm not sure how palatable they'll find them.

Boots Treat Street Trolley Dash

Another thing I made at work. Pink, isn't it?

This was the project I was using Corona for, as mentioned previously. So technically this is also my first ever Android app, although that side of things was really an afterthought — and a whole world of hurt with it.

The project had originally been pitched to the client as a Tiny Wings clone (because original ideas are hard), but it ended up more closely resembling Canabalt, with the simple tap-to-jump mechanics. Only the zoom-out on max height jumps remains to hint at the original 'inspiration'.

Graphics were chiefly the work of m'colleague Chloe (with sister Rosie helping out on faces). Trivia for the day: Chloe also provides all the vocals. One day I will set up "Naughty Doggie!" as her new e-mail alert sound.

A Few Thoughts on Cross-Platform Development with the Corona SDK

I'm writing the first draft of this on a train, heading — by an admittedly circuitous route — for Update Conf. As part of the programme we'll be treated to a presentation on using the Corona SDK for cross-platform (iOS and Android, although I believe there are rumblings about Windows Phone 7 support) development. Since I've just (almost — flipping clients) finished a project using Corona, I thought now would be as good a time as any to reflect on the plus points and pitfalls I found while using it — if only to get straight in my mind whether, when I run into Ansca'a representative, I should offer to buy him a drink or give him a slap.

The obvious first question is, Why did I choose Corona? The project — a fairly simple game for a major high-street brand, which hasn't gone live as of the time of writing and which I therefore cannot name, so well call it Basket Bash for now — needed to be developed for both iOS and Android in a short time frame (or at least, that was the original intention. Our deadlines have a habit of slipping…). There was also going to be a certain amount of design iteration along the way (meaning that we didn't actually know what we were making when we started. Again, standard operating procedure). After wasting some time trying to put together a simple 2D GL engine of our own, I gave up and started looking for something a little higher level. Cocos2D was considered, since there is now an Android port, but this would mean writing two versions of the game, one in Objective-C and the other in Java. What we really needed was a write-once solution, and this is what Corona ultimately offered us.

So would I recommend Corona? With certain reservations: yes. Much as I enjoy writing code just for the satisfaction and challenge of it, there's a lot also to be said for simply making stuff, and occasionally limiting or inelegant as it is, Corona generally gets out of your way and lets you concentrate on doing just that. The development language is Lua, which if you've never used before you'll find is simple, easy to pick up, and does just about everything you need it to do with a minimum of fuss.

My main reservation in recommending Corona — probably because I was bitten by it only very near the end of development and so the memory is still painfully raw — is Android device support. As of a few months ago, Corona does not support Android devices running ARMv6 CPUs. As of only a few weeks ago, this was not mentioned anywhere obvious in the documentation, such as alongside the Android v2.2 requirement. Since ARMv6 phones include the HTC Wildfire S, apparently the cheap handset de jour which I'm seeing advertised just about everywhere at the moment, this could be a problem. (I'll admit that I share the fault for not discovering this earlier. When builds wouldn't install on our test Wildfire, I put it down to a combination of un-optimised assets and my inexperience with Android. If I'd taken the time and dug deeper I would have found this enforced limitation — which at that stage would probably have lead us to abandon Corona, although for what alternative I have no idea.)

My other reservations probably come from the way the Lua runtime is implemented. Lua has a rich library of code available to it, but Corona will not work with any of the many binary libs. In our case, this lead to us having to abandon interfacing with a web service using AES encryption. In general, you are restricted to whichever advance features the development team have included and exposed. This includes OpenFeint, Flurry, and an older version of the Facebook Connect library. For Twitter or Facebook using OAuth you'll have to roll your own solution (unless I decide to share mine…). There is support for a selection of native widgets, although this is naturally less fully-featured than that available through the native SDKs. I have yet to attempt to use Corona to build an app with a native UI look and feel.

Be warned that debugging can be a nightmare. The SDK comes with its own simulator, which simulates the differing screen sizes of iPhone, iPhone 4, iPad and half a dozen Android devices. (You'll probably find that supporting different screen sizes is the biggest challenge in cross-platform development. Corona is pretty helpful here, if you're willing to cede a certain amount of control. It offers a number of content scaling modes and supports automatically loading assets based on the scale factor between an arbitrary content size of your choosing and the actual screen size of the device. This is basically the iOS-style @2x, only far more flexible, allowing you to specify many different asset sizes.) The simulator provides console output and a debugger. It cannot, however, run native UI widgets such as web views. For these you will have to build the project for either the iOS simulator or a handset. Which is where things get complicated. I've been unable to get console output from any of these devices. You think debugging with printf() statements is fun? Try debugging with pop-up alerts.

Builds are carried out on the Corona servers, meaning you need an internet connection at all times. For Android that's all you need (saving access to the SDK later to allow you to create a distribution key pair), but for iOS you'll need Xcode 3 installed. A paid subscription is technically only required to build App Store or Market versions of the final app, but I'd probably recommend getting it as soon as you've decide to commit to Corona, since it also gives you access to the daily builds, which in my case fixed a few compilation problems I came across.

In general, I think Corona is a great system for doing a certain subset of cross-platform development. It has the enormous potential to allow you to quickly assemble and test projects and deploy them for both iOS and Android. It's probably not a good fit for apps — as opposed to games — although I say this more out of the opinion that native apps should be built with native SDKs, rather than any kind of hard-won experience. If you are aware of Corona's limitations and manage expectations accordingly, you should find using it to be an incredibly productive experience.

Everyone Else has it Easy

I forget what we're blaming for diminishing attention spans these days. Is it still television? Or have we shifted the blame on to Twitter yet? Are we even still decrying the general inability to concentrate on one thing for more than a few minutes without our minds wandering, fingers and eyes not far behind, or is it just taken as a given that anything more substantial than bite sized chunks will go untasted?

I'm a writer, and those who practice every single other kind of artistic expression have it so much easier than I do. Among the finger painters designers I work with, Dribbble is becoming more popular. I am deeply envious of both it and them. I wish I could get feedback in a similar manner. Images lend themselves to quick inspection and comment. The visual is visceral, it elicits an emotional reaction (or lack thereof) immediately. Sure, a great first line does the same, but then you've got to follow it up with a second, and a third, and keep going until you've got where you want to take the reader. And let's face it — reading takes a lot of time and effort.

It's often been commented on on Writer's Cafe — my sometimes literary haunt of little choice — that the only writing that gets reviewed is the poetry. This isn't surprising. Poems tend to be short, hardly more than a single sparsely-covered page, and therefore quick to read, to form an opinion of, to finish with, sum up, and move on. (It doesn't help that the site is populated with writers — rather than readers — but that's another complaint.) There are few art forms which require such an investment of time from their consumers as the written word.

I publish the few things I write in order to get feedback so that I might become a better writer. I write short fiction because it allows me to experiment quickly, and I had hoped that the shorter form would encourage more reading and more feedback. That doesn't seem to have happened. So what's the solution? Simply, to go long. My one full-length piece of work has received more downloads — paid downloads, no less — that all my short pieces together. I'm sure there's some interesting psychology at play here: maybe by taking the time to publish to a store, and make the decision to charge, you're signalling to the potential reader that what you've written has value and is worthy of their precious time.

Maybe. Whatever. So it looks like I'm bringing my plans forward, skipping over the remainder of the learning to write through dozens of short stories part, and going straight to the first novel. Well, probably a novella. Let's not go crazy. And maybe I should actually write it, rather than writing about it...

A Quick Walk

I went out for a quick walk yesterday. Since my new route home from work has been taking me over the canal at the edge of Regents Park, I thought I'd take the time to have a wander and explore it. I headed west, arriving after a short while — and a single, rather confusing detour away from the canal side — later at Little Venice.

There I left Regents Canal curving southwards and followed the Grand Union further west, passing this collage / mural along the way.

My target was an intriguing patch of green which had previously leapt out at me from the map. Named "Meanwhile Gardens", it of course couldn't hope to live up to its name. Long and narrow, like most areas of communal land in London it featured rough tracks meandering through green hummocks. There was a concrete bowl of a skatepark, various assemblages of adventure playgrounds with swings and climbing frames, and a series of stagnant ponds, falling in steps of thick green weed. There was also this handy plaque, showing you where you were — spatially, in relation to the planets, and chronologically, in relation to the dinosaurs. Handy.

I followed the tow path further west, to the next easy exit point, which happened to be close to Kensal Green cemetery. Now, say what you like about the Victorians, but they certainly knew how to do death. The weather was just on the wrong side of bad for it to be really atmospheric, but there was a pleasing dampness in the air which leant a spring to the dark, pine-covered earth and brought out the green of the moss coating the granite tombs.

Then it was down Ladbroke Grove — somewhere I know chiefly through the writing of Michael Moorcock, and which had until then been as unreal to me as Tanelorn — and then home.