Archive for June 2011
I’ve written and tweeted before about webservice API’s that make it difficult to figure out what you’re doing wrong… but at least those gave me some kind of feedback that something was wrong. The worst are services that give you no feedback what-so-ever. If anything my name is attached to ever does this to you, let me know immediately!
My Latest Experience
We use SendGrid to send emails from our platform. Could we have done it ourselves? Of course. But reliably delivering emails is a lot more complicated then you would think, so we decided to go with a trusted company. We’ve been using them for months and honestly they’ve been terrific!
This week I was tasked with estimating a solution for our users to be able to reply to emails we send. My first thought was our own SMTP server since we have the code in the NewsGator platform. But moving an SMTP service in your own datacenter to Azure turned out to be more difficult than I wanted.
My former CTO (who actually wrote the SMTP code I was working with) pointed out to me that SendGrid had its own solution for email replies. I was pleasantly surprised with how easy it looked – and its SendGrid… they’ve been great! They even had step-by-step instructions on how to get everything configured. This included writing and deploying our own REST endpoint as well as DNS/MX configuration stuff. Not a trivial task but it looked so easy I went for it.
About 6 hours later I had talked to the right people in our company to get the DNS/MX setup correctly, rolled my own endpoint, unit tested it and deployed it to our production environment. Now for the big test… send an email to our MX domain and watch it get parsed by SendGrid and passed to my endpoint. I sent the first email. Then the second. Then the third, fourth, fifth and sixth. Nothing.
OK – what’s going wrong? My emails aren’t bouncing (I tested. GMail bounces invalid DNS lookups almost instantly). My unit tests work so my endpoint is correct. So I logged into the SendGrid dashboard to see if it would tell me what’s wrong. Nothing.
Finally it hit me – what account type do we have and what’s supported with it? I didn’t setup our account so I honestly didn’t know the differences.
On the dashboard our account is listed as a “Recurring Account”. Cool. So I went to the pricing matrix – no “Recurring Account” type there.
Well shit. Back to our account page. Clicked the “Upgrade Account” button. Ah! “Current Package: BasicPlan: $9.95”.
Back to the pricing matrix. No “Basic Plan”.
Oh for fucks’ sake.
Well the “Bronze” plan is $9.95… and there it is… the red X in the column for Parse API.
I had to sign into our SendGrid account to configure it correctly to use the Parse API. Presumably it knew at that point what account type we had. It should have never let me go ahead with configuring this feature. At the very least it should have told me when I was done that it wouldn’t be enabled until we upgraded our account. Instead I got nothing but an hour of detective work to figure out it wasn’t a problem with my code.
**Have we upgraded? No. $9.95 vs. $79.95 isn’t a small upgrade.
My point here is that if you offer a tiered service plan, make it EXPLICITLY CLEAR EVERYWHERE what options are available and which aren’t. Hide them or disable them (which is better is a whole different UX discussion… but choose one!). Not giving feedback anywhere along the way is a horrible experience!
My guess is that I’m the first to stumble upon this with SendGrid and based on our experience with them they will rectify this as soon as they can. They have been a great service to us. I hope they’ll do the right thing and I’ll still recommend SendGrid for anyone who needs to send email via Azure or for any other situation where you need your email delivered reliably. But hopefully if you’re creating one of these services you’ll remember my story 🙂
** I don’t have the authorization to upgrade our account. I’ll revisit if we do.
Testing CoreData Migration is usually my last step before submitting to the AppStore. Typically I label my last successful released version in Mercurial, then when I’m ready to submit again I pull that source code into a different directory and run it in the debugger. This creates my old sqlite database. Then I can run the new code and make sure the migration is successful.
I ran into an issue yesterday though with my latest release where I didn’t have the right version labeled in Mercurial… so I wasn’t sure how to get a copy of the old sqlite database. After an admittedly lazy tweet, @ideal1st put me on the right track – “Download a datastore from your device, pop in simulator and run mapping model on it“. But I wasn’t quite sure how to get at the Application directory. A quick Google search later I found iPhone Backup Extractor. From there it was easy…
1. Download the existing app from the app store and run it
2. Take a backup in iTunes
3. Use iPhone Backup Extractor to grab the Documents and Library directories of my app which has my sqlite database file
4. Run the new code in the iPhone Simulator
5. Navigate to the Documents directory of the app in the simulator and replace its contents from what was in the backup
6. Run the new code again and verify the migration
Glad I did too. I had an issue where an attribute was getting an invalid type, but a quick look with SQLite Database Browser helped clear that up.
Hopefully that helps someone else. I’d love to hear better suggestions as well!