Friday, August 22, 2014

Z Minus Ten

So I finally got around to watching  Brad Pitt's Zombie Apocalypse movie World War Z.

The central conceit is FAST ZOMBIES!  Fast fast fast! And it's surprisingly effective.  Fast Zombies kick your ass.  Fast Zombies outrun the soldiers.  Fast Zombies swarm like ants.  Fast Zombies make faster action, Fast Zombies spread the Zombie Disease Fast Fast Fast!

Cities fall, nations tumble, Fast Zombies threaten humanity! 

After a while the acute observers (mostly Mr Pitt) have noticed two things about the Fast Zombies:

1) They are attracted to noise.

2) They don't bite people already infected with other deadly viruses.

So, ladies and gentlemen of the Joint Chiefs, what should we do?

A) Develop a vaccine that makes healthy humans look terminally ill so the Fast Zombies will ignore us until a resistant strain of Fast Zombie Virus emerges and Brad Pitt can make a sequel; meanwhile blow up much of our infrastructure trying to get rid of the leftover Fast Zombies.

B) Build giant tar pits with sirens in the middle.

Hmm, tough choice, better ask the scientists...

Tuesday, June 10, 2014

Merging the Apps, Merging the App Stores

Apple’s recent World Wide Developer Conference revealed many exciting new software technologies, about which I will surely write more at some point. One interesting thing is that there is much better integration and communication between iOS and OSX on the horizon.

This got me thinking: why are there still two Apple App Stores?

(Why are they so awful is another question, and out of scope for now.)

Right now you can make an app for iPhone; or for iPad; or for both iPhone and iPad; or for the Mac. You would usually use the same tools to make any of these.

Why not merge the stores, and also merge the apps?

Merging the stores is a fairly obvious idea. It would mean using the "normal" (Mac) App Store to buy and manage mobile apps on your Mac. That might be a nice opportunity to get mobile devices out of iTunes once and for all, but again: out of scope.

Merging the apps is perhaps less obvious, but more and more iOS apps are spawning Mac versions. Wouldn’t it be cool if the developer could sell all three versions as one package? From the developer’s point of view it would probably involve uploading separate apps and simply merging them administratively. OSX and iOS are not likely to be the same thing any time soon, so in terms of binaries we are still talking about two apps.

But in terms of user perception we are talking about one app with three incarnations. I think people would get used to this very fast, and come to think of a good app as being available on all their devices automatically.

Not every developer would take advantage of this at first. Consider the Omni Group, one of the best independent software companies in the Apple ecosystem. They make some great software and they are not shy about charging real money for their products. I have one of their apps, OmniFocus for iPhone, iPad and Mac, and I paid three times for the privelege. Now they have released a new version as a paid upgrade (still pending for iPad) and I will probably, sooner or later, pay them three times again, because I believe I get sufficiently premium value from these premium products to justify their premium prices.

But for smaller developers looking to maximize their users’ engagement, it could be a big win. Or for Silicon Valley startups trying to metabolize their large injections of venture capital and desperate for eyeballs lest their Social Meatball World be overtaken by Meatball Cloudface LLC. You need to get on as many devices as possible, and get people to use your software as much as possible, before the Samwer brothers come out with Wolkenfleischball Sozial Total and lock you out of the German market.

As a user and a customer, I would like that. I want all my apps in one place, at least administratively. I want one "Purchased" tab. I want things that interoperate between my devices. I want to open iTunes as infrequently as possible.

Apple wants 30% of everything. Should be an easy match, no?

As a developer, however dilettantish my engagement with XCode may be, I find it exciting to think about making apps that are integrated out of the "box," as it were. Imagine, for example, an online banking app. Some things you really want to have available when you’re out and about, and some things are much easier to do on a "real" computer. Or think about all the things you can do (soon) with Apple’s new Health app. This begs for a desktop/laptop companion app.

I think Apple will merge the stores at some point. I have no idea when, and it would be silly to speculate considering I’ve seen iTunes as a dead man walking for years now. But sooner or later I think we will have one app store, at least for Macs.

Will they allow the apps to be merged as well? I hope so. I see a lot of benefit to it. But I could also imagine this waiting until some day, probably at least five years from now, when the operating systems themselves merge and you could have a three-platform app (or four, with the TV) that really is a single app.

Merged or not, I think the future of a lot of app categories is tight interaction between the phone, tablet and desktop/laptop versions. Doing this across platforms is much more challenging, and I have a hard time imagining the integration ever being very good. That might give Microsoft a much-needed boost to its mobile business, because at the moment only Apple and Microsoft are capable of tight integration throughout their respective ecosystems.

If I’m going to be so rash as to predict something, then it's this: by this time next year there will be a bunch of indie apps offering a unified user experience on iPhone, iPad and Mac, and at least a couple will be popular enough that the conversation in the developer community will be largely about that integration.

Labels: , ,

Wednesday, July 10, 2013

Sending Error Responses in Poet

I'm playing around with Poet, a new Mason-based web framework in Perl.

You can read more about it here:
http://www.masonhq.com/

One thing seems under-documented: how do you deal with error pages?

Well, you probably noticed there is a directory called "static/errors" and in it there are things like "404.html" and so on. So far so good: these are what they appear to be.

But how do you trigger one?

The documentation for Poet::Mason shows a very useful method:

abort (status)
clear_and_abort (status)
    These methods are overridden to set the response status
    before aborting, if status is provided. e.g. to send back
    a FORBIDDEN result:

        $m->clear_and_abort(403);

    This is equivalent to

        $m->res->status(403);
        $m->clear_and_abort();

    If a status is not provided, the methods work just as
    before.

Great, so all we need is:

<%init>
    # you can't see me!
    $m->clear_and_abort(404);
</%init>

and... boom! You are served the standard 404 page from your "static/errors" directory.

But what about a 400 BAD REQUEST, which is more likely to be needed in the first place? Just changing that status code to 400 gives us... only the status code in the response headers, and a blank page. At least that much worked.

But a quick look at "static/errors" shows there is no "400.html" -- and all we need to do is drop one in, right? Wrong. Or half-wrong anyway: we do need to create that file, but just creating it isn't enough.

It turns out this is controlled in "bin/app.psgi" (around line 20). The command:

enable "ErrorDocument",
    map { $_ => $poet->static_path("errors/$_.html") }
    qw(401 403 404 500);

So now we just add a "400" to that list and restart the server, right?

RIGHT!

Hope that helps.

Tuesday, June 25, 2013

RuPy Conference October 11-13, 2013

Do you do Ruby?

And/or Python?

And/or open-source in general?

If you answered Yes to any of these questions, then
you should seriously consider attending the
RuPy conference in Budapest, Hungary. It’s this
Fall, October 11-13, 2013. The weather in Hungary is great that
time of year, very autumnal but not too cold. I will be posting
more on this in the coming months, as I plan on attending myself.
But for a start, here’s the web site:

http://13.rupy.eu/

Labels: , , , ,

Monday, April 15, 2013

CanoScan LiDE 200 on Mountain Lion: Failed to open a Session on the Device because it (the Device) was Locked!

Just a very quick tech note for the Community, since it took me way too long to solve this problem: assuming you have updated your drivers and so on, if your CanoScan LiDE 200 (or similar Canon scanner) still gets you an error in Image Capture on a Mac, the scanner might be locked.

The lock switch is on the bottom of the scanner.

I had by then already updated the drivers, but I probably didn’t need to. Unlock; unplug; re-plug; re-launch Image Capture; voila. It took a while to warm up, but then it had been in storage for two years (which is of course why it was locked).

That did the trick for me. Of course it would have been lovely to have the software say “Your Scanner is Locked, Dumbo!” But I guess it’s a more secure lock if you forget it’s there!

Labels:

Wednesday, January 11, 2012

How Third-Party Apps Should Use Siri

Apple’s Siri is a “digital assistant” for iPhone 4S and, presumably, various other products to be released in the future. I expect it will come to the Mac at some point too.

I haven’t used Siri, but I have been following the developments because I think she (in the UK, apparently a he) will become a very big deal once there is an easy way for third-party applications (App Store apps) to take advantage of the voice recognition and natural-language processing Apple runs on its servers.

There has been a lot of discussion online about how this could be done without various apps stepping on each other’s toes. If I say “Siri, remind me at six about Tarkan’s birthday party,” which calendar program will it use for the reminder?

In this case, it will obviously use Apple’s. You could make that configurable but I really doubt Apple would.

I think the answer is as easy as it is obvious, and easier than it is awkward. Apple controls (approves) the name of every app in the App Store. It can easily allow developers to choose a “Siri Name” for an app, also subject to central approval. Keeping these unique should not be hard.

Then you simply tell Siri whom to tell (or ask) what. Much like you did in Applescript, if you had a Mac in the 90’s (or are a total masochist today).

For an app named “Candy Store,” it might go like this:

HUMAN TO SIRI: Siri, ask Candy Store if they have blue gumdrops.
SIRI TO CLOUD: <...sends audio...>
CLOUD TO SIRI: Parsed OK for "Candy Store" : "find 'blue gumdrops'"
SIRI TO APP:   find 'blue gumdrops'
APP TO SIRI:   OK, in stock, $6/dozen.  Options: order, view.
SIRI TO HUMAN: Candy Store has blue gumdrops for six dollars per dozen.
               You can view them or order them if you like.
HUMAN TO SIRI: Order six dozen please.

Siri would of course know the context of that last command, because Siri is tracking a conversation and not just individual commands. You could also be very direct:

HUMAN TO SIRI: Siri, tell Candy Store to cancel next week's shipment.
...
SIRI TO HUMAN: Your Candy Store shipment of four hundred mixed jellybeans
               for Monday, January 16 has been canceled.

If I were Apple I would start this with a very, very simple API, supporting only the simplest directives like “find” and “order” and “do,” but also sending the original text to the app in case the app wants to do its own parsing.

But that’s probably way too utopian of me. Apple will no doubt wait until there is a huge NSDigitalAssistantRequest API and statically-typed conversations and 30% of any digitally-assisted sale going to Cupertino, and start with three hand-picked third-party apps for a year-long trial run before mere mortals are allowed in.

Even then, it could of course be huge.

Labels: , ,

Sunday, November 20, 2011

Meta: old comments published, sorry.

I just realized I had not moderated comments in six million years.

So I did, and published the non-spammy ones. In case there is some kind of notification system and you get an e-mail that your comment from 1932 has been published on this blog: my apologies for the tardiness.

Labels: