a glob of nerdishness

January 17, 2012

The web is its own platform

written by natevw @ 1:57 am

Web apps are not cross-platform apps.

If the battle is whether Apple’s tools or HTML5 is the best way to write iPhone apps, whether Google’s frameworks or HTML5 is the best way to write Android apps, whether Windows Presentation Foundation or HTML5 is the best way to write Windows apps — my money’s on “native” in any and every case. Some developers aren’t as bothered by oppressive distribution policies as they are by the differences between platforms. They see JavaScript as the new Java — write once, run anywhere — and see generic-but-native-looking HTML5 apps as superior to the native apps they mimic.

The trouble is that users don’t value “consistent across platforms”. Why would they? They expect consistency within a platform. Developers who look at web apps as a “cross-platform solution” because of “HTML5″ do themselves a double disservice: not only do they devalue their own app by making it subtly inconsistent to native iPhone apps, they devalue the foundation they’ve built upon by muddying the web’s unique consistency.

Interestingly enough, it was Apple’s experiments that in large part sparked what we now call HTML5 — even before they tried to pitch web technologies as the iPhone SDK. Their 2004 introduction of Tiger’s new WebKit features, and their use in HTML-based dashboard widgets, was not uncontroversial — especially the debut of the <canvas> element. The controversy was not just about a browser adding this new element ahead of the standards process, but whether its nature fundamentally fit the web.

This wrestling may have been too quickly forgotten when the zeitgeist turned to The Web vs. Flash. Which one did we want in our pockets? Which one would we allow into the App Store? (We know who shot a rather rich mixture of fuel across that flame too!) Cute young <canvas> livened up that party, while the more web-ish SVG kept faithfully raising the children back in her own namespace.

Now APIs for 2-dimensional, and perhaps someday 3-onto-2-dimensional, drawing at such a low level as <canvas> provides is one of the most native-ish things a sandboxed web page could hope to ever do. But what distinguishes <canvas> from Flash? Very little as far as the topic at hand — the user experience may certainly benefit indirectly from an open standard implemented by competing vendors accessible from the same code that manipulates other document content, but its fundamental direct nature is one of a rectangular garden in which every website may try to plant its own reimplementation of superficial patterns and behaviour borrowed from hither and yon.

Like Flash, <canvas> is a useful medium for games. Games are their own platform. There are certain habits in game design; one of these patterns is that every game paints its own interaction. The Web, too, is its own platform!

Should the web platform shun games as one of its many contents? Certainly not! The web is a platform for content — perhaps the platform for content — and I’m beginning to suspect that that is exactly how a web *app* should look and behave as well. And not just any content, but linked content. Hyperlinked hypercontent for hyperconnected hyperhumans.

Raw pixels do have a place in that, as do video and audio and maps and molecule models.

You may recall me puzzling, in my early days of transition from desktop interfaces, at the attraction of building “apps” on what began as the physics paper platform. Just as physics is discovering what a tangled web may lie beneath their spherical cows of uniform density, it’s becoming harder and harder to ignore just how revolutionary “sharing within internationally dispersed teams” was even just for some academic information. And the web was never intended to be limited to a single format, so the idea of applying it — finding applications of it — building web apps for any task that can be turned into information, is not unfounded. Because of the web, any part of our lives that can be turned into content is limited only by the velocity of its light cone and the weight of its incoming links. It’s a powerful, powerful platform.

(The web’s other attraction is not unique to the web: any medium seems to gather a healthy school of builders who may not understand the first thing about foundations but are willing to keep bracing lumber together until they find an arrangement that’s worth tying a rope swing beneath. However, the web platform is actually especially conducive to this; how many of us don’t look back fondly at the first tree forts we built, that were our early homesteads in this great forest?)

So what is “native” to the web? Cloning every desktop and mobile operating system into a least common denominator cross-platform app framework has failed before, and it will fail again. I even see a very low return on investment trying to mimic the design patterns and interaction behaviours of only The Mac (or the iPad, for that matter) with the new tools HTML5 has given. The Macintosh interface was designed for specific hardware and a rather earlier period of transition. Not to mention, its modern implementation has much deeper consistencies and broader features than the different 80% each one of us relies on, which varies whether we’re keyboard people or mouse people, know Emacs meta shortcuts or copy/paste, have a multi-button scroll mouse or prefer a braille display. A web app’s best bet is not to pirate these patterns, like a camcorder snuck into a matinee, but to embrace the medium of hypercontent it’s been given.

That’s really what the web is: important information, flexibly found and presented, easily shareable via links. Since the web is not the world, people need specialized means of integration between their lives and whatever information they care to share by projecting it into existing and still-missing forms of content. Making that better is what web apps are.

October 20, 2011

Creating a self-signed S/MIME certificate for Mac and iOS 5 email

written by natevw @ 12:43 pm

Today I needed to send some passwords to someone over the internet again. The recipient recommended using PGP/GPG to send an encrypted email, but unfortunately that protocol appears to be quite a hacky hassle if you use the built-in email clients on Apple’s (and apparently Microsoft’s) platforms.

Fortunately, iOS 5 just added support for a more standard protocol called S/MIME, and so I had recently come across a nice article on setting up secure email on both Mac OS X and iOS 5. Since I mostly want S/MIME for email encryption rather than signing (there’s a good overview of the distinction on its Wikipedia article) I decided to just create a self-signed pair rather than procuring a certificate from some annoying, overpaid and insecure centralized certificate “authority” as that article recommends.

Creating a self-signed S/MIME certificate is actually very quick and relatively easy using the Keychain app that comes with Mac OS X, but I wanted to document the process as getting a certificate that Mail recognizes did require overriding at least one of the assistant’s defaults:

Update: Turns out Mozilla Thunderbird will not accept the certificates generated through this process. I’ve had success by creating a standalone personal certificate authority and then using that to sign a user-only certificate. I need to test it a bit more before writing it up here, but it might be a bit simpler process in the end.

  1. In the Keychain utility application’s menu, choose “Create a Certificate…”:
    Self-signed S/MIME certificate creation, figure 1
  2. I had to override the defaults primarily so I could include my email address necessary for Mail.app to use it:
    Self-signed S/MIME certificate creation, figure 2
  3. Confirm that self-signed is okay
  4. I just accepted the default serial number (1) and validity period (365 days)
  5. Then the part where you enter (at least) the email address you want to use this certificate with:
    Self-signed S/MIME certificate creation, figure 3
  6. For the actual keypair, I went with DSA mostly just because:
    Self-signed S/MIME certificate creation, figure 4
  7. I unchecked all the certificate metadata stuff in the next 4 steps, you can try playing with it but didn’t seem worth the complication:
    Self-signed S/MIME certificate creation, figure 5
  8. Then just have the assistant create it in your login keychain unless you have some different setup. It will take a bit to generate the keypair.
  9. Once it’s created you’ll need to find the certificate and double click it…
    Self-signed S/MIME certificate creation, figure 6
  10. …so that you can manually trust it for at least S/MIME:
    Self-signed S/MIME certificate creation, figure 7

Once you’ve done that, you’ve taken care of the “The Certificate” step and can just follow the rest of the instructions in Ars Technica’s “How to secure your e-mail under Mac OS X and iOS 5 with S/MIME” article using the certificate you created instead of one from some corporation.

There is one major drawback to a self-signed (decentralized) certificate. As you’ve seen yourself after creating your certificate, it will not be trusted by default — only several dozen corporations and governments and rogue nations are trusted to forge certificates; you are not on any platform’s pre-approved issuer list. So: after you give your public key to your email contacts (as will be necessary for them to decrypt your messages) they will have to repeat steps 9 and 10 above to manually trust your self-signed certificate on their own machine.

July 2, 2011

Parting questions for PalmHP

written by natevw @ 2:51 pm

To be clear, I LIKE webOS and want it to succeed. :/
Steven Frank, 2011 July 1

One of my first memories of Palm’s new “New Palm” thing was when they were in the papers every month for making their first webOS device pretend to be an iPod. For USB syncing purposes. Clever way to get some free advertising from MacRumors, but you know what? I hate what iTunes has become and loved being able to just drag and drop MP3 files onto my Palm Pre 2.

Anyone wanna buy a Palm Pre 2?

I tried to love it, just like how for years I’d been trying to love the heavy, bulky reel mower I also bought online. It’s good for the ecosystem, it’s got some very very nice qualities designed into it…

I’ve decided I don’t like either the lawnmower or the smartphone. And while I don’t need perfect landscaping in an efficient amount of time or energy, with greater responsibility at work comes greater need to join the same technological century as the rest of the world. Even though I’ve owned a Palm Pre 2 since last December, it’s never felt okay nor have I had room for it on my person. Thus it was not until this week that I became a cellphone person.

More honestly: I am now an iPhone people. It seems like such a silly insignificant change to go from having an iPod touch always in my pocket to an iPhone always in my pocket, but for me it is a defeat.

When something fails I wanna know why. So here are some poignant, probing questions that will magically make Palm/HP awesome again:Good questions are hard please read the following rants instead:

  • what’s with the HP logo when my phone reboots? The original palm wordmark was a reserved, artistic logo. The new .(h|p)*…thing is a glowing gradient of a corporate wart that only calls all the nice things the Palm people have said about their acquisition into question.
  • for example. why is “http://h41112.www4.hp.com/promo/webos/us/en/smartphones/pre3.html” the URL for the Palm Pre 3 (and why is it down while I’m trying to gather info for this post?)
  • why is the Palm Pre 3 still only [no worky web page, no getty authoritative tech specs...] X millimeters “thin”-ner than the mainframe computer I am typing this on?
  • why does it still have a stupid slidey keyboard thing that I could never shake the feeling would remain in my pocket when I accidentally pulled out only the other half?
  • why, after I really really really wanted to love my Palm Pre 2 but couldn’t, am I now completely uninterested in any incremental non-improvement you’ve not really made at all since then? Since the very first Pre?!
  • I know HP used to be a great company and all, but can you please just license the poor operating system that still somehow shows the most spectacular promise of being potentially both usable and open, try taking it and licensing it to a company that might actually be capable of combining it with some decent hardware before it’s too late?
  • and also: I said “potentially spectacular” operating system, not “actually spectacular”. Pls to put a hard-driving perfectionist in charge of software. No more Mr. Nice People, otherwise only Mr. Nice People will be able to say Mr. Nice Things about the promising prototype-grade rubbish you keep. shipping.
  • Buying an iPhone was a defeat because now i’mStuck with iCloud instead of a Synergy plugin that could talk to data on a server I control. Now i’mStuck with iStore monopolies instead of your fun official instructions for owning the device I bought. Now i’mStuck with the same iPhone that everyone else and their soccer mothers all sport like a luxury item because a truly useful phone still is — and it’s cheaper than yours!

    But the saddest thing about it all is that this sticks me with an even better web browser — w00t! — than I got on a platform called webOS. So even while Apple keeps shoving native adults into a sandbox, they’ve also been pushing web technologies up towards where I suspect native vs. web will meet: the same amount of power, but on the latter: the freedom to innovate that only a real platform can provide.

    The web is the only tool developers have left. I feel defeated because it’s not thriving as or even on anyone else’s operating system and I don’t know what that means.

    June 26, 2011

    The Continued Adventures of ShutterStem

    written by natevw @ 12:33 am

    The working motto is that ShutterStem is “trying to make taking photos fun again”.

    And it’s this nebulous dream, and that’s okay for now.

    Some moonbeams for holdy paws:

    • so iCloud is a relief. I doubt they even sync metadata, but at least Apple finally woke up and realized that they needed to do something about the iMac sitting at home not being useful most of the time.
    • sync was gonna be the killer feature that made the world beat a path to ShutterStem’s door, but giving everyone a private server without needing everyone to be a devops ninjas and/or having to make hardware etc. etc. is a Hard Problem even with a CouchDBs at ones’ disposal.
    • so it’s nice that iApple have tackled the low-hanging fruit and the 90% may soon have something practical, useful, and just works, while still meanwhile I “trying”
    • what is an ShutterStem? then?
    • the medium-term goal is just a collection of tools that shows off why I heart CouchDB and how it can help a small niche of photographers who insist on doing some things the hard way (=my dad and me and you if you want) get things done a little more easily and better…ly
    • so you’re rewriting stuff again and this will never be finished?
    • probably? look. this is not just an audacious dream of a platform for photos, but it is also a platform for a bunch of audacious ideas about how the web should just connect people to extensions of their own selves and to extensions of each other, rather than be the warrantlessly searchable home of all our eggs in one basket. this kinda stuff takes time, filing out all the paperwork through the proper channels and whatnot if you aren’t impressed with ill-fated shortcuts

    French Revolution?! Where were we. Oh yeah…

    • photos fun again?

    So I’ve had this vague notion that my photography hit some something and then wasn’t fun anymore. That’s really all this little ShutterStem hobby is about…playing with the slightly more “revolutionary” side of some neat technologies to somehow somewhere get back to the days where I were outside taking pictures that were fun to look at again and again. It doesn’t matter that App Stores are evil or any other stupid politics… I just wanna help make some photo app that kinda surprises and delights even in its nichey nerdishness.

    So what’s the wall, where maybe should I push for revolution?

    I wonder if it’s…if it is related to my capacity for mental inventory? I have a bunch of gadgets…but I know where each one is, and all its accessories. I have piles of books…but I can picture each one on the shelf in my head. I have tons of deadtree and digital documents…but I can generally track down the one I’m looking for. I even know where, within our two-year old’s scattered arsenal of real and supposed toys, the better part of half our kitchen utensils likely lie….

    But I might as well be backing up a bazillion blurry photos, because that’s the haystack that one day my brain stopped looking for needles in. And I wonder if that’s when photos stopped being fun?

    So besides being OpenDoc, besides being Unhosted, besides being W3C or RFC-worthy or maybe instead of any of all of that, ShutterStem just needs to help me [help anyone] INTERNALIZE THE INVENTORY. Helping as only computers can help. ing.

    • Q. Does that mean I’m starting over with yet another prototype(s) instead of shipping some sort of v1.1?
    • A. Meh.
    • If you’re sticking along for the ride I’d hate to bore you.

    October 23, 2010

    The final straw

    written by natevw @ 4:35 pm

    From Calf Trail’s farewell post:

    With the announcement of the Mac App Store, Apple has broken any lingering hope I had for one day succeeding at indie Mac development. Being treated as a responsible adult, innovating without restriction, connecting directly with customers, and being able to fix my mistakes quickly — the things I cherished most about my job at Calf Trail — are being gradually replaced by a “submission” process.

    Today I gave all my Cocoa code to github; up for adoption or left for hospice care, I don’t know.

    May 22, 2010

    The right Orwell

    written by natevw @ 12:39 pm

    I’ve sneered at Apple for calling the iPhone, iPod touch and iPad “revolutionary” when their App Store’s economic model seems a bit outmoded. But the devices are impressive, and while Orwellian comparisons referencing the 1984 ad are fun I haven’t been totally convinced of the analogy. Thought control is really more Google’s goal: knowing the world’s information and making it universally adsensable. All Apple control is the means to publication (German: Publikationsmittel) on their revolutionary new cropland.

    Orwell’s 1984 wasn’t about a revolution and its metaphors are more apt for pervasive, world domination type situations. Orwell did write another book, however: a much funner read that just happened to be all about a revolution. So without further ado, I present:

    The Animal Farm SDK Agreement

    I wonder — what will be this revolution’s “Four legs good, two legs better” moment?

    April 12, 2010

    Glastnost sold separately

    written by natevw @ 12:39 pm

    Last week Apple held a press event and updated their developer agreements in anticipation of a major upgrade to their iPhone OS. One change in the App Store rules has been generating quite a lot of news: Apple now forbids writing applications using anything but native tools.

    Much has been written about what this means for cross-platform toolkits, game engines and advanced programming techniques. Certainly, if this rule is taken to its logical conclusion, App Store developers can’t even invent programs in the shower. In short, Apple continues to bring “innovation” to their digitally restricted “revolution”.

    But I agree with Michael Tsai in this article: “I doubt that Apple cares whether applications use libraries or interpreters or parser-generators for their engines.”

    It’s surprising to me how many dozens of articles have focused on a tiny little extension of Apple’s incredible power over App Store developers. The written rules have changed a bit: so what? Apps still get rejected for all sorts of unwritten reasons or just sit unapproved for “continued study”.

    Why is this? The official answer came last week, and it’s straight out of Orwell’s 1984: “There’s a porn store for Android…so we’re not going to [stop censoring apps].”

    Translation: “We have triumphed over the unprincipled dissemination of facts.” to quote from Apple’s own “1984″. Either Steve Jobs has been buried by the confusion of his own Doublethink, or he is a liar. There is nothing right about pornography, but the best solution Apple can come up with is dressing every iPhone, iPod touch and iPad in a corporate burqa, strings attached to their Cupertino Ministry of Plenty?

    So Android owners have the freedom to succumb to sensual lust, just like iPhone users can browse to any site they desire in Mobile Safari. It’s not the business of any corporation to have any say in what freedoms me or my children have. All Apple needs to do is take the provisioning infrastructure they’ve had in place for years, and give the user the right to decide which developers to trust. That’s all.

    Until then, we are talking ourselves to death. I am certain now that either Apple hates the App Store and loves the HTML-based SDK they originally announced, or they love power and hate independent developers. Against evidence, I’ll give them the benefit of the doubt and go with the first option.

    Web applications must overcome many technological, usability and privacy deficiencies. They cannot (or at least, should not) provide a native experience on most devices. Dealing with broad spectrum of screen sizes and browser capabilities slows down web development. While this means I won’t have time to whine much about some megalomaniacal yet innovative corporation down in California, it also means it will be an interesting challenge. And I do like interesting challenges.

    I hope I’ve made myself abundantly clear through my many tweets and blog posts on this tired subject. I no longer have time to waste thinking, complaining or explaining about the dystopia of App Store development. Just as I enjoy listening to the music of Shostakovich despite the influence of Soviet censorship, there are so many beautiful and user-friendly apps that have been approved for these devices. I am happy that there are developers willing to produce under the conditions.

    I’ll be even happier if a free world of decentralized Web technologies can compete well enough to encourage Perestroika in the motherland. Maybe then I can return. Until then, I’ve got some work cut out for me.

    January 28, 2010

    A Gradual Divestment

    written by natevw @ 10:13 pm

    I’ve been thinking about the last two years’ investment on a number of levels. Regarding the platform I chose, I’ve been struggling to find the right words for several months. I came across them today, at the end of a dead-on post by Alex Payne:

    Wherever we stand in digital history, the iPad leaves me with the feeling that Apple’s interests and values going forward are deeply divergent from my own.

    I’m most energetic while inventing a self-contained tool to improve some aspect of life. Writing native software for OS X was a dream come true. I hope the Mac’s open platform has many good years left, but it’s time I learn to enjoy building native software for Chrome OS as well.

    September 22, 2009

    Be careful when using Uniform Type Identifiers

    written by natevw @ 6:14 pm

    Someone posted a lengthy article today (here, and cross-posted here) claiming that even though Snow Leopard ignores creator codes, applications can use Uniform Type Identifiers to match a file in a generic format to a specific editor. As far as I can tell, someone is wrong on the internet.

    There are two potential problems with expecting UTIs to take the place of creator codes as the article claims. The first is that applications are not encouraged to make their own app-specific UTI if one already exists. Consider the case of a JPEG file, which is a common format that many apps can open. With creator codes, an app that creates a JPEG file could make it easy for the user to re-open it later in the same app by setting its creator code. In common practice, an application would just be using the predefined “public.jpeg” UTI when dealing with JPEG files, instead of an app-specific code, as Apple had never encouraged otherwise.

    Using an application-specific UTI even when a predefined one exists is a clever idea. Update: no it’s not. Doing so would mean no other app could open your app’s files. That would be bad, too. Or it would be, if not for the second problem. A file’s UTI is determined by Launch Services, and there isn’t a good way for an app to set one itself. (I would love to be wrong on this!) When Launch Services needs to know a file’s UTI, it looks at the file’s extension and picks just one of potentially many matching system and application defined UTIs.

    Launch Services’ behavior in this regard is no better than file extensions. It’s worse, in fact. Consider a “.log” file: This common extension could be used for a system log, an application history, a GPS tracklog or any number of file types. If an application lets a user open any file with the “log” extension, it will be able to open its own files just fine. If, on the other hand, an application wants to use the new, shiny, recommend UTI system and offers to open files with UTIs of “com.example.tracklog” instead, it sets itself up for failure. If Launch Services has decided that the “.log” extension means “public.systemlog”, all .log files will have that type and the user won’t even be able to open a file from within our tracklog application itself.

    Uniform Type Identifiers are a neat concept, and I recommend you use them. They do offer many advantages, including the potential to eventually replace creator codes in a future version of OS X. But you must use them with care. The main pitfall is Launch Services. You can use UTIs and UTI concepts so long as you always keep in mind that a file may have a completely different UTI on a user’s machine than it does on yours. When creating an open dialog, include the extensions you may be able to open in addition to UTIs. When defining a document type in your Info.plist, use the old (deprecated!?) CFBundleTypeExtensions instead of LSItemContentTypes. Otherwise, another application on your user’s system could end up overriding your extension’s UTI and your application will be unable to open its own files.

    Launch Services should really report a different UTI based on which application is requesting a file’s type, or report a set of all potentially matching UTIs instead. This would affect some file-handling parts of the Cocoa framework as well. I reported this problem with the current way file UTIs are assigned in rdar://problem/6590416 this past February. I hope it can be fixed, because Uniform Type Identifiers are a win in the long run.

    May 9, 2009

    How I resume incomplete ADC downloads

    written by natevw @ 9:38 pm

    If you follow the Apple news/rumor sites, you’ll have heard that Apple has been (pre-)releasing software like crazy lately. I can neither confirm nor deny these rumors. Between my marginal ISP and the dank, dusty cellars underneath Apple’s public website, I get plenty of half-finished large downloads regardless of what Apple is up to.

    When Safari thinks it’s finished downloading an incomplete file, I like to use curl to finish. My usual trick isn’t enough for the Apple Developer Connection’s password-protected files, and it took me a while to figure those out. Eventually, with the help of two helpful posts and some trial-and-error, this is the method I’ve settled on:

    1. Copy partially downloaded file if it’s fairly large (because sometimes I mess up)
    2. Log into ADC in a browser, and copy the download link
    3. curl -c $(mktemp -t curl) -L -o '<Partially Downloaded File>' -C - '<Download URL>'

    It is very important to quote the Download URL, because it may contain special shell characters! This is the main reason I copy the partial download; I don’t want to blow away a large partial download with a bit of error page HTML.

    This works as follows: -c $(mktemp -t curl) tells curl to keep track of cookies in a temporary file, and -L means to follow redirects. The downloaded output file is specified via -o and -C - means to continue at the offset where this output file stops. I don’t include an option to automatically retry on failure, because if the session expires this could lead to a loss of the newly appended data if the download is replaced by an error page.

    Next Page »