Irfaan

I also consider the Facebook requirement obnoxious - up until I decided to give Grouper a spin, my Facebook profile was minimal, not even a profile picture. But I was curious enough that I bit the bullet and gave Facebook way, way more information about myself than I'd normally be willing.

Which, of course, makes the vapor nature of the service that much more upsetting.

My experience could very well be an aberration - that said, I figure I'd throw out a warning to others interested in trying to service but are hesitant to give Facebook more personal information.

I'm... not sure how to parse that sentence. I guess it's implying I have a non-trivial amount of stupidity, which probably explains my parsing problem.

Transit routing is a hard problem to scale - Apple has taken a shortcut and pushed it off to 3rd party developers, who can tackle the much more approachable problem of solving it on a city-by-city basis. Which make sense... but this is still a large regression as far as users are concerned. And doesn't help folks that live in smaller cities.

Yes, Apple is probably working on this. But now we come to an odd signalling issue - Apple has basically told 3rd parties that it is worth their time investing in this area. If-and-when Apple opts to plug this functionality hole, they've pulling the rug out from under these developers. And any app developer worth his salt has to be factoring that.

And I'd be really surprised if Apple steps in any sooner than the next iOS refresh - fixing transit seems like a wonderful bullet point for iOS7.

"Loosing iOS users for some barely noticeable amount of switchers is hardly a good business for Google [...]"

Err... what are they losing, exactly? Users aren't inherently valuable. If there's value these iOS users add to Google, I'd love to hear it.

Google is already generating local search and behavioral data via their large Android install base. Beyond brand visibility (which is going to be reduced, thanks to Apple's own offering), what does releasing their own native app get them? A native version that, again I want to emphasis, Apple is actively competing against their own product. Whatever Google releases, it is now going to be a 2nd class citizen, without the OS-level hooks Apple's own solution gets. And this assumes that Apple even lets them release an app. This wouldn't be the first time Apple has blocked Google from releasing an application on iOS because it duplicates existing 1st party functionality.

Basically - why should Google release their own app?

"—do they even make money from Android phones someone sells? I heard Microsoft makes more money than Google does."

I don't think I can adaquately address this in a response to a comment. Google is not a charity, and Android does add to Google's bottom-line.

In closing - I'd fucking love it if Google released a native Maps app. I'm an iPhone user that's gotten bit by this, and am sticking with iOS5 for now. But I'm not going to hold my breathe waiting. Particularly when I don't see a compelling reason for Google to save me.

If I were in Google's shoes, I wouldn't be launching a native Maps app. Period.

It's not like Maps is driving vast amounts of search revenue for Google. And with the degraded functionality of Apple's own Maps app, Google's Map app has become a reason for a buyer to consider switching to a Google-blessed Android phone.

And I say this as a long-time iPhone user - Maps was an important application for me. Now that it's become less functional, I'm going to actively look at Android and WP.

So - I have a hard time believing he's going to let Fiddler fall apart. If anything, he's finally getting an opportunity to make it his priority, and with an actual development team backing him, I'm actually excited to see how far he can push Fiddler.

tl;dr - I don't have faith in Telrik. I do, however, have faith in Eric.

If neither Amazon nor Google's brand recognition hasn't convinced folks (buyers or sellers) to start pushing it instead of PayPal for Internet purchases, I can only hope it's because their solutions are equally terrible - otherwise, I have a hard time seeing how a new player will make headway in this space. And I'd really like a new player. :/

And that's a terrible mistake. I don't care how capable my Angry Birds experience is on my camera. I care about applications written to enhance the photo-and-videographic functionality of my camera.

I'm fine with Nikon throwing on a custom launcher, if that's what they need to do to work around Android's touch-focus. I'm fine (and in fact, prefer) folks authoring applications specifically to the Nikon camera's interface.

And there's so much opportunity to extend a camera's capabilities, once it can run 3rd party applications. Auto stitching panoramas. Unwrapping spherical maps. Chromakeying. Instagram-esque filters. Subject tracking. Realtime preview and control over wifi and bluetooth via companion devices. Panning motor control. Multiple camera's automagically synchronizing. Etc etc.

The author uses Parrot's Asteroid car stereo system as an example for how a non-standard usage and non-standard UI are bound to fail. But that's a really weak comparison. Who do you think is more likely to grow a robust 3rd party ecosystem - a one-off experiment in a crowded, cost-sensitive market (a $350 device for bleeding edge enthusiasts), or an oft-upgraded stable of professionals who are already spending multiple thousands on equipment to be more productive?

The alternative is Nikon creates their own OS and development environment. But why compete with a flourishing platform, when you can just simply use it?

Is the server-side ecosystem for Linux-hosted C# production worthy? And if so, does it compare well to the solutions getting recommended in this thread?

Adobe is emphasizing that they have to do more compositing logic, so they they need an RGB version of the video frame on the CPU side.

If they did the colorspace conversation on the GPU, they'd have to pull the converted image back and incur the latency hit. Apparently, they see less latency in doing the conversation on the CPU, and have made the call to trade processor efficiency for latency.

To be clear: YUV colorspace conversion on a GPU is really damn simple. I have a ~30 line shader that does it from my video processing codebase. But I can take the hit - I do a substantial amount of image manipulation using shaders on the GPU, and mask the read latency with heavy multi-threading. A Flash application doesn't have this luxury.

But this discussion is largely academic - if you're writing a Flash based video player that doesn't need the flexibility of Flash's full compliment of image manipulation and composting functionality, you'd be using their StageVideo API - an API that does do all the video work on the GPU. This API was introduced in Flash 10.2, which came out after this article from 2010.

instead of "0<x%n&", you should be able to do "x%n&&". Works for me on Chrome.

My goal is to shave 2 bytes, so you can change the key handler back to onkeydown. :P