johns

You've got something really great so far. I'd start charging immediately :)

Even if you have a webcam a chat is still useful to share links, etc that aren't code. I'm betting a lot of people would use comments in code as an ad-hoc chat.

If you're wondering what some of the discrepancies are, I wrote up a bunch here: http://john-sheehan.com/post/41653656681/the-good-and-the-ba...

Been using PayPad for Stripe for notifications and stuff and love it. It's a little more mature so if you are looking for more features (like entering payments right from the device) check it out.

FB definitely sends access token via URL param for the server side flow: https://developers.facebook.com/docs/howtos/login/server-sid...

If there were a mitm they could get it even if it's in the hash. It has to travel to the client at some point.

IFTTT will let you easily do RSS to email too: ifttt.com/feed

I wrote this about a year ago for an intro to how I think you should design APIs based on my time at Twilio: http://john-sheehan.com/post/18688963163/dont-build-the-best... Hopefully it helps.

There are a lot of different types of APIs (partner, SaaS, internal/mobile, infrastructure, etc), many of which you can use as a part of building a business.

Never build a business freeloading off another business. The social and consumer API providers are realizing that their APIs don't drive value to their core business objectives (selling subscriptions or ads). APIs are a means to an end. The end has to benefit both sides. Don't blame the means for faulty ends.

A great way to get webhooks to the client is through some sort of real-time push service. Either homegrown or something like Pusher. You'd have to listen at a webhook endpoint then re-create the event in Pusher, but the client would be simple. Pusher might even support creating the event directly from a webhook, I can't recall.

If you don't want to maintain the webhook listener, create a script on webscript.io to listen and create the Pusher event.

The current voice of esurance (post Allstate acquisition) is John Krasinski of The Office.

Among other things, not having to set up your own XMPP or IRC server.

This is awesome. One nit: if I pick a route, then the bus leaves there's no easy way to 'refresh' the route and get a new timer without backing all the way out and starting over or going to more routes and doing the time math.

Prove your hot shot abilities through OSS and countless companies will line up to put you in that kind of environment.

You still have to write the Ruby layer if you want to appear in the list. I think they should get rid of the Ruby file requirement.

At this point aren't they big enough to shift the onus onto the service providers to create hook endpoints that all accept the same payload? I don't see any reason why the service hooks section needs to be anything more than a list of URLs you want hit. You could still list all the providers and just automatically create proper URLs for each service. No need for the Ruby layer. IFTTT and Zapier and the like can fill in the rest for those that don't want to create the webhook interfaces.

Tweeted during the blackout: https://twitter.com/BWWings/status/298245437373177856

The tricky part is for services like IFTTT (where I used to work) and Zapier (where the GP works) where you do want an authorization to be indefinite and not require user interaction because it's a background job.

My understanding, and it may be wrong, is that if an attack walks off with your data, then wouldn't be able to refresh the access token you have on hand without the client ID and secret and so the extent to which they could compromise the authorized accounts is limited in time.

OAuth 1.0a is far too complex. OAuth 2.0 for the simple and common cases is not that bad since there's no signature to generate.

Most of the issues from OAuth 2 stem from a fluid spec that wasn't finalized until recently. Now that that's done hopefully the situation will stabilize and once you learn how to use one (I also recommend making the requests directly yourself and not using a library) you'll easily be able to use all the others without having to search out all the quirks I wrote about in this post.

Would be interesting to hear more about how you built it.

Is it automated?

This is a nice gesture, but I prefer the services I use to take responsibility for their provider and technology choices. Your customers don't care that Azure is down, they only care that they can't do whatever they were trying to accomplish. This isn't Azure's fault. It's yours. Don't pass the buck.

I was working a variety of software and IT jobs mostly related to Microsoft tech in MN before I got noticed by a head of marketing for an up and coming developer tools startup who gave me a job.

When will input and button size classes (e.g. input-xxlarge) be normalized as hinted to in the current docs?

I'm a big fan of niche job boards (I run api-jobs.com). I think the pricing might be a little high without some broader distribution though. For instance, featured listings on my site are syndicated on ProgrammableWeb.

Either way if you can find an untapped niche, they're pretty easy to run for passive income.

Also check out bootswatch.com

Wouldn't that be a GitHub repository?

This needs to be clarified on sauceio.com/mac. It's very confusing right now to go to pricing and not understand what it's for.

Exactly. Site44 only uses Dropbox for the sync, then serves out the site over its own infrastructure.

Email Twilio support, they can help you with that (I used to work there)