Let's talk about customer support. It's your first line of defense when customers are affected by bugs, so it should be a very high priority.
Of course I'm being set off (again) by ongoing issues with PhoneGap Build. Probably around 80% of my work is developing PhoneGap based mobile apps. And again, the site is experiencing issues...
This particular problem is not even one covered in my previous rant. They have (when occasionally bothering to respond to customer support tickets) mentioned that there were issues with the process that does compilations notifying the website that compile was complete, for one or two platforms. Well, if I had to guess, I'd say the issue is now more widespread. I uploaded a build around 2 hours ago and it still hasn't been marked as completed for a single platform.
But that's not what I'm flying off the handle about, today. No, today is about Time Zones in relation to customer support.
For the uninitiated, there's this whole section of the planet in a time zone called US-East, where a shitload of people — yours truly included — live and work. And while they don't post profiles of all of their employees, we can extrapolate based on their posting habits and the occasional twitter bio, and estimate that Adobe has two teams working on PhoneGap Build: One in India, and one in San Francisco, California.
These two time zones are almost directly opposite one another, so you might think that between them they could cover customer support needs fairly well; in 12 hour blocks, with one team handing over everything to the other team at the end of the day, never going un-covered.
Woe, but were that true.
Instead, what seems to happen is that at some point in the Indian late afternoon or early evening they punch out, and the customer support portal goes dark for the night. While it does feel a bit rare, subjectively, let's say that when the SF team wakes up and heads into the office, they do in fact pay attention to the support portal. It often doesn't feel that way, as someone who's under deadlines and frustrated with a support black-out, but let's give them the benefit of the doubt for the sake of argument.
If the India team stops handling customer support at 5pm in their local time, and the SF team starts handling support at 8am in their local time, then there's a chunk of time un-covered there. At first glance that time block doesn't seem so bad. It's 5:00pm until 8:30pm in India, or 4:30am to 8:00am in SF. But if we look at that time frame for US-East, that's 7:30am to 11:00am — basically the first half of every day is radio silence.
Not just radio silence, but when a big problem happens, like, you know, NOTHING WORKS, then we're sitting on our hands and our deadlines for half a day waiting for someone, anyone, to come save the day. When my applications are useless I get a notification, and I drag my ass out of bed no matter what time it is, and I don't go back to bed until it's fixed.
This is geographic discrimination, and it suuuuuuuuucks.
And let's be honest here: they're not jumping on tickets at 8am in SF. More like 11am, if at all.
I know I sound like a broken record, here, but come on guys. This service is the fucking cats pajamas... when it works. To quote a colleague of mine, if you could keep it online we would "fly to California just to throw a stack of money at you."
For at least two weeks now they've responded to every one of my "hey, btw, your service is down" tweets, more than 12 hours later (often even 24+ hours later!), with something along the lines of "sorry, we're making some changes soon to address this!". I don't think your definition of "soon" and mine are the same.
Published 2013-05-21 @ 11:02 in
12 Responses
Adobe
PhoneGap
For those of you who will be coming to our group outing to the Twins vs. Red Sox baseball game on Saturday evening, here's what you need to know logistically.
We'll congregate on the 2nd floor near the bridge into the mall, after the conference closing remarks, and plan to catch the 5:12 train -- that should leave plenty of time to use the restroom and drop things (e.g. your laptop) off back in your hotel room before we leave. You won't be able to bring any food or drinks into the ballpark, so don't plan on bringing them with you. Please try to meet at the rally point by 5:00. Don't forget your ticket!
The train station is just a short walk across the sky-bridge and through the mall:
You should probably also plan to eat dinner at the ballpark -- game duration can be a bit unpredictable but you should expect at least 3 hours (plus a ~45 minute ride back).
The forecast is currently calling for (potentially) some light rain, and temperatures in the upper 70's & low 80's (that's F... 24-27 C for you Brits). Personally I'll probably just plan on getting a little bit wet. A little water never hurt anyone! If you didn't pack any rain gear and you're so inclined, I'm sure there are places in the mall that would be happy to sell you a poncho or rain coat. The stadium should also be selling ponchos, but supply may be limited and you can expect them to overcharge.
In order to streamline the train-catching process, please try to take a few minutes to run down to the train station tonight or tomorrow and purchase your light rail tickets. We're going from Mall of America Station to Target Field Station (and back again), and each leg of the trip should cost USD $1.75.
Enjoy the rest of the conference, and if I don't bump into you before Saturday afternoon, I'll see you then!
Published 2013-05-17 @ 05:23 in
No Responses Yet
cf.Objective()
One of the most common complaints I hear about Taffy is that it requires that you extend its base class in your Application.cfc...
component extends="taffy.core.api" {}
Sometimes you don't want to do this. Maybe you have another base class you're using, or you just don't want to. Whatever your reasons, it's a dealbreaker.
Talking with Chris Phillips at cf.Objective() today, I had an epiphany that it should be possible to get Taffy running without extending taffy.core.api from your Application.cfc. The only reason it's been a requirement thus far was to automatically bootstrap in Taffy's handling of the onApplicationStart, onRequestStart, and onRequest events.
But if you're willing to wire those up manually, you can write your Application.cfc any way you like as long as -- at some point -- you hand off the request to the appropriate Taffy method. Here's an Application.cfc that uses Taffy as an internal object without using extends in Application.cfc:
component {
function onApplicationStart(){
application.taffy = createObject('taffy.core.api');
application.taffy.onApplicationStart();
}
function onRequestStart(thePage){
application.taffy.onRequestStart( arguments.thePage );
}
function onRequest(thePage){
application.taffy.onRequest( arguments.thePage );
}
}
You can put whatever you want before and after those calls that defer to Taffy's internal implementations (e.g. the rest of your application), and it should still work exactly as described in the documentation -- variables.framework would still be used, etc -- but I haven't tested this extensively yet.
Just a little tidbit that I thought some of you may be interested to hear.
Published 2013-05-17 @ 04:06 in
3 Responses
Taffy
We're all people. I acknowledge that. Nobody likes getting yelled at. So I apologize in advance for what I'm about to do. I don't mean to hurt anyone's feelings, but if nobody speaks up, we can never expect change.
I used to think that my personal Hell was getting stuck head-first in a small space and not being able to squeeze back out (claustrophobia like woah)... Today I'm officially changing my personal Hell to long-standing bugs that affect a significant number of people and get little-to-no response, resolution, or worst of all, communication on what's taking so long.
I'm looking at you, Phonegap Build.
I would rather get stuck in a tiny space than continue to put up with your bugs and lack of communication on their resolution status.
The worst part is that I fucking LOVE Phonegap Build. Independent manual builds for multiple platforms suuuuuuuuuuucks, so this service was begging to be built from day 1. The often-buggy or for-some-reason-offline debugger (weinre) is pretty sweet, too... when it works. If you were to start charging for the service, my company would be first in line with our checkbook open, fervently clicking our pen over and over until you named a price and told us to whom we should make the check payable.
But for fuck's sake, it's been nearly a year since it was reported that you're building android apps with the wrong icon in place for XHDPI (highest-resolution, aka best-screen) devices, and it's just a matter of copying the correct file into a folder before you compile the damn APK. It's so rudimentary that I've managed to write a tool that completely automates the fix including repackaging, re-signing, and re-zipaligning. If it's just a matter of copying the correct file into a folder, why hasn't it been fixed? And if the issue is not that simple, why aren't you communicating that to us? The icon is a pretty damn important part of an app, Android has the highest market share, and XHDPI devices are getting more and more popular every day.
It was 9 months ago (August 2012) the last time Adobe commented at all on the issue, and that comment claimed that the bug should be fixed. The slew of comments since then says otherwise. What... the... actual... fuck?
Moving on...
I've reported over and over that linking to external sites in a way that opens the device's native browser, rather than taking over the Phonegap Webview, does not work as documented, or at all, for that matter. I first reported the issue on April 5th, 2012 -- more than a year ago.
I've got an app that I just upgraded from Phonegap version 1.5 to version 2.5, recompiled by Phonegap Build, and here's how external links work:
- iOS
- do abso-fucking-lutely nothing
- Android
- open the link in the Phonegap Webview
And yes, I've tried every possible permutation of white-listing the domains (search for "<access", since they don't expose any deep-linkable ID's... fail, fail, fail, fail...). There's also this user-proposed "navigator.app.loadURL" solution, but for some god-forsaken reason, Phonegap doesn't support the "navigator.app" object (at all!) on iOS -- it's Android only, by design. (Way to provide a consistent API across devices there, guys...)
Considering the number of links that modern apps generally want to open, this is a big fucking deal.
There's good news for this issue, too, though. According to the Phonegap 2.7 documentation (note that at the time of writing, the latest Phonegap version supported by Phonegap Build is 2.5.0), a new syntax will be available for opening links using the ChildBrowser plugin and the device-native browser:
window.open('http://google.com', '_blank'); //childBrowser plugin
window.open('http://google.com', '_system'); //device-native browser
That's great and all, but we don't have 2.7 support on Build yet. On a whim, I tried both syntaxes on my Phonegap 2.5-based app built with Phonegap Build -- and it works... mostly.
window.open('http://google.com', '_blank'); //childBrowser
This syntax should open the childBrowser plugin, and as far as I can tell it seems like that might be what it's doing, but the top of it is getting cut off -- I can only see a few pixels along the bottom of the url bar and buttons, so it's kind of a guess. Whether or not it's trying to load the childBrowser plugin for this, it's not working properly.
window.open('http://google.com', '_system'); //device-native browser
Almost as if by magic, this seems to work. I couldn't believe my eyes. I took a closer look at the Phonegap 2.5 documentation and wouldn't you know it? It's documented.
Why haven't they been communicating this to us in the bug reports? I never saw it before today because I had been trying to avoid the ChildBrowser if possible. Only by giving up did I find the answer. Fail, fail, fail, fail, fail.
I can live with bugs. I have plenty in my own projects. I do not accept bugs + a year without resolution + no communication. This is stupid, and not in a good way.
Again, I don't want to hurt anyone's feelings. I'm not trying to get anyone fired. What I am trying to do is get you (Adobe) to communicate more effectively. Reply on bug reports (more than once a year, please), and if fixes are not what we expect then let us know it's going to take some time. When you shrink away into the shadows, it makes us feel neglected and abandoned, and that does nobody any good.
Published 2013-05-09 @ 10:14 in
No Responses Yet
This November I'm running a marathon to raise money for Children's Miracle Network. But instead of running a marathon I'll be playing an epic 24 hour video game marathon.