Tom Insam

Facebook and OpenID


She stumbled upon a solution whereby nearly 99.9% of all test subjects accepted the program, as long as they were given a choice, even if they were only aware of the choice at a near unconscious level. While this answer functioned, it was obviously fundamentally flawed, thus creating the otherwise contradictory systemic anomaly, that if left unchecked might threaten the system itself. Ergo, those that refused the program, while a minority, if unchecked, would constitute an escalating probability of disaster.

The Architect

Oh, sorry. I was going to write something about Facebook making noises about openness. I must have got distracted.

While passing through an airport recently I bought myself a new Nintendo DS Lite, and Ninja Gaiden - Dragon Sword. I’m not going to bother reviewing it - I’m bad at that. But I loved it, in large part because I enjoyed playing the Xbox version ages ago (it was hard) and it plays very similarly.

The whole thing controls with the stylus (and holding any button, which blocks) and it all feels so fluid. It retains the feeling I remember from the xbox, which was that you were always moving somewhere, hitting things, but it never really felt that things weren’t under control. I’m impressed that somehow the two games play so similarly, given that the control scheme is so vastly different. All the same things worked - Flying Swallow still works well on certain sorts of enemies, others need proper block/attack synchronisation, collecting essence still works the same, you still have an annoying motivation to find a good group of respawning enemies next to a save point and farm them for money till you can buy all the upgrades… And the camera is a pain, though much less of one than in the Xbox version. It’s a fixed viewpoint, and pans, which works well except when you’re far enough away that it’s hard to judge depth and you’re flailing away at things you can’t hit.

It’s a lot easier and smaller than the first one. It’s still linear, but has a hub-and-spoke level design, a central area from which you open progressively more portals. I preferred the Xbox game, which had a long linear-ish progression that looped back on itself, bringing you back to old areas sometimes, but never in a way that made you feel that they were hubs. Well, maybe once. Being given a list of ‘here are the portals that you’ll be able to open, you’ve opened these, this one is next’ feels like a cheap way of indicating progress through the game. Maybe people like this sort of thing. But the Xbox version felt better as a story telling vehicle.

Anyway, I liked it.

Flame for the iPhone

I’ve been playing with iPhone development recently, and have ported Flame to it. Well, re-implemented, really - Flame is written in Python and there’s no PyObjC for the iPhone, and nor is there likely to ever be. But Objective-C is getting easier as I get practice, and this app even has a modicum of proper memory management.

This time, the source lives in GitHub/jerakeen as git seems like the cool kid this week and I need the practice. I’d expect it to build and run in the simulator just fine, and it runs on my device, so it’ll run on yours if you know the magic hoops to jump through. It’s possible that this app might actually make it to the App Store at some point, though it’s somewhat niche.. You never know.

Let me know if you have ideas for improvements. For a start, I’d like certain services to be linkable - HTTP servers should open their web page in Mobile Safari if clicked, for instance.

On syndication

 

13:19 <@jerakeen> I have worked out how to syndicate my WOW achievements into my jerakeen.org lifestream.
13:20 <@The> it's becoming a "no life" stream

Trivial. But interesting to me - Addressbook.app no longer cheats with it’s startup image - it now uses a static default.png like everyone else. It also seems a lot readier to quit when you run something else, whereas it used to stay resident. This makes me happy. It starts very quickly, and it’s nice to pretend there’s a level playing field.

Notes and Maps still cheat with their startup images, though.

The iPhone iPod ‘podcast’ section used to list video podcasts, but only played their audio tracks, which was odd. Now (as of the 2.2 firmware) it’ll play video podcasts as well, which is nice. For a start, I can take the ‘video’ button off the tab bar at the bottom and free up a slot for something more important.

Weirdly, it’ll play the video in portrait mode (as well as landscape mode), whereas the video section of the application will still only play them in landscape mode.

Unsubscribe

Unsubscribed from LMN Tactical Newsletter

You really want your template language to automatically escape all strings unless they’re flagged as ‘I know this contains HTML and I know what I’m doing’. This stops many trivial forms of cross-site-scripting attacks.

You probably also want certain columns of your database to be annotated in such a way that your CMS doesn’t accidentally display them to users.

Startlingly, the webkit-based browser on the iPhone supports the HTML 5 client-side storage standard. Alas, you can’t write properly off-line apps because there’s no local HTML/file cache on the phone you can keep files in. You could use the bookmarklet trick I suppose, but I don’t like that one - it’s nasty, and makes development annoying - you have to keep re-syncing things, it’s not terribly easy to upgrade, etc.

I do, however, want to write local apps in a language that’s a little higher-level than Objective-C. It’s nice and all, but I prefer things to be more flexible. The iPhone SDK agreement means that I can’t write my code in a high-level language and ship an interpreter, alas - no iPhone pyobjc for me. But (and this is speculative, I’m not a lawyer, etc etc) as I read the iPhone SDK user agreement, I think you could probably write a pure HTML/JavaScript application, using the webkit local storage engine, and run it in an embedded webkit view as a local iPhone application.

3.3.2. [..] No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

(emphasis mine)

This means I can have a shippable application, with local storage, but with large bits of logic written in JavaScript. I may even be able to intercept requests for urls and call API functions from Objective-C space, so I can expose location data to the application, for instance.

There are obviously huge disadvantages to writing an app in HTML, but I’d like to try it if only as both a rapid prototying environment for local apps, and a way of giving apps that are already HTML-based some local storage and the ability to be run when away from network.

Unfortunately, I feel that I can see where this could get taken. The spirit of the SDK agreement is clearly that Apple don’t want any way of distributing applications except through the App Store. This exception is in the SDK only because you can’t have an embeddable web browser widget without saying ‘stuff the web browser does is ok’. But if this loophole actually is a loophole, I don’t see what stops me writing a front-end that can download more HTML into the local storage area.

Well, no, actually, I see

3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store.

..which might cover that one. Maybe I’ll write something like this as an experiment anyway.

Here’s another thought. If I can intercept requests and call Objective-C functions, why do I need the HTML-displaying part of this at all? How introspectable is Obj-C anyway, and can I ship an Objective-JavaScript bridge in my app?