Recently it was included in GitHub for Windows, so I'm very proud of that. So check that out if you use .NET. I also recently launched a website called API jobs. It's a job board for all of the best jobs that are out there in the API industry at companies like Twilio and SendGrid and Pusher and more that we'll talk about later.

So you can go there if you're looking for a job. I am starting a new job on Monday at a company called If This Then That. So If This Then That lets you connect all of the internet services that you use in interesting ways. So if you want to automatically save your Instagram pictures to Dropbox or save Twitter favorites to Instapaper or you can do things with Google Reader, Evernote.

There's just tons of combinations. You can combine them however you want in these recipes and automate your life essentially. So check that out at IFTTT.com. These are some other companies I worked for. I worked for Twilio for a couple of years building the developer evangelism program there and working on developer experience.

And most recently I've worked with AppHarbor, Stripe, and Xamarin and I'm an advisor to AppHarbor and Xamarin. All right, so we want to talk about the cloud today. So first, you know, we should get everyone on the same page and really define what cloud means. So, you know, the definition of cloud is a meaningless buzzword that any company uses to replace the word internet. Like, you've all seen this. To the cloud.

Or maybe not. That's Microsoft's version of the cloud, apparently not even involving the internet in this case since the software runs on the desktop. The cloud has pretty much come to mean nothing. But for the sake of this talk I want to sort of narrow the scope from meaning everything and nothing all at the same time into one more focus area.

And to me the cloud means compute network storage and service infrastructure offered and managed by a third-party provider. Now even this isn't complete enough. There's the whole scaling thing and where your data is located and all that stuff. But the slides are only so big, so we'll go with that for the definition. You know, compute storage and network. This is a really well-defined area.

This is something most people are pretty familiar with now. It's pretty well-defined and scoped. Companies like Amazon Web Services, App Harbor, Heroku have done a really good job of sort of solidifying these three services. So I don't really want to talk about these today. I'm kind of bored with talking about hosting when it comes to the cloud.

So what I want to talk about instead is the service infrastructure part of this equation. And what that means. So let's start with a couple of examples of what kind of cloud services are out there that I'm talking about when I mean service infrastructure. So for example, email. You want to send email. Yeah, you can set up an SMTV server. You can manage your mail server. You can all do that. Or you could use one of these services.

SendGrid, Postmark, and Mailgun. These let you send and receive email. So we'll talk about how the receiving works later with webhooks. But essentially what this does is this is managed off somewhere else in the world. And you don't have to think about it. All you have to do is make and receive HTTP web requests, which as web developers is something that we're intimately familiar with and can do without even batting an eye at.

So no more infrastructure to maintain to send email. There's the telecom area. So Twilio is a really big player there. Send and receive phone calls and text messages. Nexmo is an SMS provider with good worldwide coverage. Make it really easy to send and receive text messaging and make and receive phone calls without having to set up your own infrastructure. If you've ever tried to set up telecom infrastructure before with like Asterisk or FreeSwitch or any of those things,

you know what a pain in the, you know what it can be to try and get those things working. Let alone getting them to scale and using them on demand just isn't possible when you're building your own infrastructure. You know, it's sort of like the latest crop of these cloud services are sort of the real-time providers.

So, you know, WebSockets and Socket.io are awesome. But building your own infrastructure on that, again, with all the benefits of the cloud, with the scaling and all that stuff, can be sort of a little bit, you know, too much for some applications. So, you know, these companies have set out to sort of define real-time as an API. So Pusher I'm going to be showing you a lot of today and how that works.

Pubnub is very similar to Pusher. Spyro is sort of another recent entry into it. And Superfeedr is based off of PubSubHubbub for RSS feeds, but that's just another version of real-time over HTTP. We also have, you know, like as mobile gets bigger and bigger, we have a set of companies that are doing mobile backend as a service completely via API.

So instead of when you want to go build your mobile application, setting up, excuse me, setting up, you know, users and data and all that stuff and having to run your own web infrastructure to complement that app, these services give that to you out of the box. So Parse and StackMob are complete mobile backend as a service companies. Shoot is around photo processing and photo handling and photo pickers and all that with some cloud integration as well.

One that I left off of here, because the name is too long, is Urban Airship, and they handle all of the push notifications of different devices and different platforms, all via API again. You can also run jobs in the cloud. So Iron.io will let you send a Ruby job off to it. It's sort of like delayed job with an API. And then it'll just run it at a specified time where you can send it a queue and you can do queuing and job processing and all that.

It's a little like, if you're familiar with like Heroku worker rules or Azure worker rules, where you could build something like this, all this queuing system, it's a little higher level than that and gives you more out of the box functionality really designed for running jobs. And MomentApp is essentially a way to schedule HTTP requests to be made at any time.

So you can, via the API, say, hey, I need you to run this URL at Monday morning, every Monday morning, and every Monday morning, I'll go off and request that URL for you so you can run some tasks. And then we have the services that we use every day, so Dropbox, GitHub, and Google, everything that Google does. Most of these things have APIs that you can access.

In some cases, you can actually use them in your apps to replace things that you may have done yourself. So for instance, if you're running an app on Heroku, you can't write to the file system in a persistent way. So if you want to give your users file storage, you could go through S3, or you could also go through Dropbox and use their Dropbox accounts for storage. And for one, that's a nice benefit to your customers because it gives them data portability on the way out.

If they leave your service, they still have all the files that they've given you already synced to their machine automatically. And then a couple more popular ones. These social APIs are like, you know, some of the big three social APIs. It seems like every social service out there has an API, and Twitter really sort of popularized the idea of interaction with a service via an API.

Now, they later take it back, sadly, but it seems like you can't launch a service now without an API or without people demanding that you have one. So the big question is, why do we want to use cloud service APIs while we're building it ourselves? And that's really the most prescient question, really, is build versus buy.

This is what everything comes down to. Why would I want to buy these services and pay as I go and start out on a free plan and grow with them or whatever, as opposed to building my own infrastructure that I'm going to be really intimate with and maybe curate and grow over time? I've got a couple reasons why you might want to do it. One is they equip you with a new capability.

So in my case, back in about 2008, I had this idea for a website that I wanted to build. I run a sports league, like football or softball league, and every Sunday when there was inclement weather, everyone would just call the hotline over and over again, all afternoon, just waiting for updates. And I thought to myself, you shouldn't have to pull the hotline.

The hotline should call you when the status changes. So I sat down. I was like, I'm going to build this. And I went, and I was like, all right, asterisk, I'm going to set it up. I'm going to learn how to admin a Linux box, and I'm going to be up and running in no time. About 20 minutes later, I scrapped that idea. I was a lonely Windows web developer, and all of that was a whole new skill that I did not have.

A couple months later, Twilio launched, and I read the post on TechCrunch, and I was running around my living room because I was so excited because it spoke my language. It gave me a capability that I did not have the five minutes before I found out about Twilio. So suddenly I could interact with telecom using just HTTP, which again is like second nature to me. So a lot of those, like some of the back end as a service for mobile apps give you this too.

Like maybe you're just a mobile developer. You're really good at doing Windows 8 desktop apps, but you're not so good on the website and building web stuff that scales or anything like that. Those can be a place where they sort of augment your existing skills to give you a complete set of skills to build your applications.

Another thing they give you is instant scale. So almost every cloud service out there, I've never seen one that doesn't claim this as a benefit, gives you instant scale. So if you release an app and it suddenly gets more popular than expected, if you're running your own infrastructure, you're scrambling, and you are in emergency mode trying to throw more servers at the problem. If you can even get them up and running and configured, and if your application was even written to run on more than one server,

you can be really in the weeds when that happens. So these cloud service providers have already taken care of that problem. They've built in scaling into the platform so that they can grow with you and they can handle spikes and dips and basically be more malleable to your application. A big one that some people seem to look past sometimes is data.

So I don't know how many of you have built an email sending system. How many of you know exactly how many emails go out of your web app every day? One? Out of the 3,000 people in this room, one person knows how many emails go in and out of a system every day.

If you were to use SendGrid, the rest of you, you would know exactly how many emails were going in and out of your system every day, how many bounced, when your peak times were, what days of the week were busy for email generation. You'd have complete history over that. These are the things that we always say we're going to build. We all have these half-assed dashboards with blank graphs that we're going to fill them up.

We're going to build all this analytics and all this data, and we're going to start collecting it from our email and our text messages and our phone calls and all this stuff. But nobody ever builds that stuff, and these services give it to you out of the box. You know, complete logging of everything that goes in and out of the system. A lot of analytics, a lot of them tie into other analytics systems like GoodData and give you even more in-depth breakdowns of what exactly you're using when it comes to the resources.

So I think those are three of the biggest reasons that we want to use cloud services. But I think the biggest one for me to just sum it all up is that cloud service APIs allow you to focus on building your application and not building infrastructure. And if you're a startup or even like a small team within a company

and you want to move fast and get a prototype out there and get in front of real users, the last thing you want to be worried about is infrastructure problems or even infrastructure design. So with cloud service APIs, you can essentially take all these pieces from all these different providers and connect them and then sort of mix in your special sauce that makes your application unique and special and valuable

and you're up and running in far less time with less infrastructure worries. All right. So there's a couple technologies in play here that are very common across APIs. I'm going to take a sip first, although this isn't my water. I don't know whose it is.

My throat's drying up, so it takes Norwegian. All right. So there's a couple different ways that you communicate with APIs, and there's really two modes. There's sort of like this half-duplex mode where you send a request, you wait for a response, or a request is made to you and you give a response. And it's sort of synchronous, not always, but it's not two sides talking to each other at the same time.

So the first thing that you do with these half-duplex communication methods is you'd be pushing data in or you'd be pulling data out. So if you're sending emails with SendGrid, you're sending them the information for them to generate the email to get sent. After you've sent a bunch of emails or after you've made a bunch of phone calls or text messages,

you might want to pull your logs out. So the technology that's most common for this is the HTTP API, frequently called REST API. I'm going to sort of avoid going into the intricacies of whether or not something's REST, but for marketing's sake, let's just equate HTTP and REST APIs together. So this is the real workhorse of the cloud services industry.

So if you go back to Amazon Web Services, which was the first really popular cloud infrastructure company, what really made them establish their position was that they provided APIs for all of their services. So you could provision servers just via API requests, or you could upload to S3 completely via API.

You didn't have to FTP everything in. It made the entire thing automatable and basically gave you full control over the resources in a way that hadn't really existed prior to that. Another thing that needs to happen sometimes is that you need to be notified. So imagine if you have SendGrid set up to receive your incoming email, somehow they need to tell you that, hey, there's a new email here for you,

and you need to do something with it. Or for Twilio, when there's a new incoming phone call, there's a new call coming in. How do you want to handle it? And generally, the way that these get handled is via a technology concept called Webhooks. Webhooks is not a standard. It's more of a style. But essentially, what Webhooks is is it's a way to assign a URL to a specific behavior

so that your application can be notified when that behavior happens. And I'm going to have lots of examples about this in a second, but I'll wait for that. And then the last sort of thing, these full-duplex situations where you want to interact in real time with something. This is becoming more and more common. And the technology that is used for this is WebSockets.

And I put Exeter on there because there are other methods for doing this. There's long polling and ten different other bastardizations of HTTP to make it so that you could have long-lived requests. But WebSockets is really where it's going and where the future of real-time conversations between your application and APIs is going.

And the reason why it's really taking off is because it's so easy to implement in the browser, and that's the most common place that you want to actually send data back and forth in real time. And so WebSockets is really where things are heading. All right, so an example of a REST API. So REST APIs are essentially the glue between your code and the service provider.

So if you have a function and you want to send SMS, then you make a POST request and you say, here's the three parameters that I want to send with it. The service replies back and says, all right, we sent the message. Here's the ID. You can look it up later. So REST HTTP API is just a simple request. They're usually based on JSON or XML, response types and messages,

and they're just a way to communicate very simply. And because they're so simple, they work for so many different scenarios. So they're really just the glue between your code and the service provider. Now, webhooks are sort of like in a reverse API.

So you may have seen this. If you use GitHub and you use a post-commit hook, or if Heroku has post-commit hooks, app hardware has post-commit hooks, basically a way for your application to be notified when something happens. So in GitHub's case, when I commit new code, it'll go off and make a POST request to the URL that I have on there, and it'll tell me, hey, new code has been committed.

And then I could have my build system or some other system download that code and do something with it. Or I could post to my campfire chat room saying that new code has been pushed and basically stay in touch with that. And what's nice is that it's just a simple POST request to any URL. And because of that, they're really easy to implement. If you can handle a POST request,

if you know how to handle a form submission on your website, then you know how to handle a webhook. So these are becoming more and more popular. And thankfully, because I love them, they're just so simple and useful. So here's an example of a webhook. So this would be a service provider making a POST request to your website. This is roughly what it looks like when an incoming call comes into one of your Twilio phone numbers.

They make a POST request to the URL that you specify. They give you some information about the call. And then you reply back with XML that controls the phone call. So if you want to speak text, play audio, connect people into a conference room, anything that you can do with the phone,

you basically send back simple XML commands from your application, and Twilio reads that and decides what to do. And the conversation goes back and forth until the phone call ends. So WebSocket, there's no real good way to put this on a slide. So imagine going back to full duplex. I don't know if you're familiar with how speaker phones work. Back in the day, they were half duplex.

So if you were talking, it would cut out the audio from the other side so you couldn't actually both talk at the same time. And now they're all full duplex because they use noise-canceling techniques to prevent feedback and such. So now you can talk on phones and still hear the person on the other side at the same time. And that's really sort of the kind of communication that WebSockets

and the related technologies allow for APIs. All right, so I'm going to do a couple of examples here. I'm going to grab some more water again first. We're going to first start out by doing a simple incoming email thing. And actually, if you want to get out your phone or laptop, you can participate in this demo, in these demos.

And at the end, you have to participate if you have a laptop because I need people in the audience. All right, so I'm going to go over here to my editor. And what I've got is a simple Sinatra website.

Sorry, the obsessive compulsive part of me needs two spaces. All right, so this is Sinatra. It's a lightweight Ruby web framework. And I just want to say I've been working with Sinatra for about three weeks. So I've previously did a lot of .NET.

So if anything goes wrong, I'm going to be counting on Rob back here to help me out because he knows it way better than I do. But essentially, what we've got here is we basically have a route handler that says when a GET request is made to the root URL, then do this action. So what I'm going to do is actually I'm going to start off

by sending an email with SendGrid. So the first thing we need to do is we need to basically create a hash of all the data that we want to send along to SendGrid. So we're going to send this in the HTTP, the body. These get translated into post parameters when the request is made.

So I'm going to start out by saying, all right, I need a parameter with my API key. And I have that in a global. And then I also need to send along my API user. I have that in a global as well.

And then I need to say, all right, who do I want to send this email to? So I'm just going to send it to myself. And then I'm going to say it's from. We'll just use test.jscian.com because I have that configured with SendGrid.

And then we'll go down here and say subject. D rocks. Got to pander to the audience whenever possible. All right, and then the text of the message will be like, this is the best conference.

And that's actually not a lie. So I'm not just saying that. All right, so I'm going to use an HTTP library called HTTP Party. And what that does is it's just a thin wrapper that lets you make HTTP requests.

And I'm just going to say, make a post request. And then put in the SendGrid. SendGrid.com API email.send.json. So this is just the API endpoint that accepts your request to send a new message and returns back JSON. And then I'm going to pass in the options.

And I'm going to just output the body. So if you're unfamiliar with Sinatra, the last line, anything that you can put after the equals sign, you can just put there and it will return it to the browser. All right, so now I'm going to save this. And I have this right here. So I'm going to do Ruby web.py.

Oh, see? This is the problem. I just switched from Python to Ruby too, so web.py is not a Ruby file. It's a Python file. I know, shocking, right? All right. So now I've got this running on my local server. So now when I load up this request, this is going to actually go off and send the email.

And see, that's the data that SendGrid gave back to me. Now, SendGrid doesn't actually give you very useful information back after you send a message. Some other services will give you a representation of that message with more information. And I felt the phone buzz in my pocket, and if I go over here to my Gmail account, you can see there's the email I just sent.

So all of that, zero configuration, no SMTP server to worry about, no separate infrastructure to maintain, simple post request so you can be up and running and sending emails in no time. SendGrid also allows you to parse incoming emails. So what I want to do next is show you sort of what that looks like. And at the same time, I want to introduce you to a tool

that was written by a former coworker of mine at Twilio. And what Request Bin is, is it lets you inspect incoming HTTP requests. So if I go here and I say create a request bin, I get this URL up here. And now every request I make to that URL, so if I were to come back to the command line and say curl foo,

foo and bar are hard to type. And then put in that URL and hit enter. This is going to go off and make a request to that. And if I come back here and if I refresh, you can see foo and bar is the request that I just made. And I can also inspect the headers.

And basically, it's an easy way to debug webhook. So I'm going to take that same URL and I'm going to go over to my SendGrid account. And I've got a domain here. And I'm going to go ahead and put that post, that URL in here. I'm going to say update host and URL. All right, so this is where you can help out.

So if you go to your phone and you type in hi at emailparty.com, which by the way, I registered that domain just for this talk. So you have to use it because it cost me $10. So if you send, actually, if you put anything at emailparty.com, then I'm going to go over here and I'm going to show you.

So hi at emailparty.com, blah, blah, blah. It's actually a language I made up. So you can also participate in this if you want. So you can see, here's a place where you get a lot more useful information. So what this has done is it's given,

it shows whether or not it passed a sender, what's that called? SPF, whatever. I can't remember what it stands for right now. If it has attachments, what character set, who it's from, all the information related to that email. So we'll see if anybody decided to play along. Thank you for participating, Mr. Dalby.

His message was, he sent his email to sexytime at emailparty.com, which means I just got a business model and raised $10 million in funding. So thank you for that idea. All right, so you can see how easy it is now to start accepting incoming email.

And you can parse out the subjects and the message and basically, I don't know if you're familiar with TripIt or what's another service like it. But basically with TripIt, you email in your travel receipts and it parses it out. It gives you a nice fully formatted itinerary. So if there was something, or like Basecamp, when you want to create a new item, you can send in an email with the to-do in the project. And then it goes off and creates that for you.

Now you can build this in your own application. So if you're looking for a way to allow users to create new issues or have your support tickets routed through this, it automatically goes off into another system. Whatever you can do with HTTP web requests, you can start doing with webhooks. All right, so let's combine these a little bit. And I'm going to use Pusher to sort of glue

these two ideas together. So the first thing I'm going to do is I'm going to add an endpoint on my site for receiving the incoming email. So I'm going to say, I need a post route at slash email.

And then I'm going to, I'm just going to, when this message comes in, I'm going to use Pusher. So I haven't really talked about what Pusher is yet, but it's essentially Socket.IO or SignalR as a service. So you can send messages between browsers and devices and websites and all of that.

Any application that can make post requests can send messages. And then any sort of browser that's listening can act on those requests. So if I show you, I can show you here the, actually I skipped a demo. I'm going to go back and do the other one first. All right, so I'm going to show you how Pusher works before I get into tying Pusher to email.

So the first thing I need to do is copy in some configuration thing. And I'll just, to save the typing, I'm just going to copy in the route too and I'll explain what it's doing. So this is basically just saying, all right, here's my Pusher application. And then I have this endpoint. So any time a post request is made to slash click, it's essentially going to trigger this event called click

and send that out to everyone that's subscribed. And what the subscribers look like is this. So if I go into my view and look at the counter, what I have here is the JavaScript syntax for setting up Pusher. So what I do is I first pass it an app key to tell it which app to listen to.

Then I say, all right, listen on this demo channel. Then I have a global clicks variable. And then I'm going to bind on that channel. I'm going to listen for the click event. And any time one of those comes across, I'm going to increment it and then write it out to the screen. And then I also made it so you can just click on it and increment it. So once I get this up, if you pull out your laptop or your phone and you go to this and you click on it,

we'll all see the number climb together. But first, I need to make sure I'm not returning a view yet. One second.

Sorry, I have a bad, my notes are incomplete. That's right. We'll make it up. Get click, do, end. And this just needs to return the herb index counter.

So that's just going to load that view. All right. So I'm going to go back over here. I'm going to say get commit am click demo. Get push Heroku master. All right. So this is going to take a sec to push to Heroku while that is going because it takes a minute. Does anybody have any questions?

No questions. All right. All right. So it's received my application now. And you can, if you have your phone or your laptop ready, this is going to be at ndc-demo.herokuapp.com. So I'm going to go there now.

And then slash click. So this is probably error until the upload is done. So we'll just wait a second here. Hopefully, we'll only have one or two other Heroku deploys in the rest of the talk because I used to do this talk with .net and App Harbor and it would be like ready instantly.

So Heroku just takes a little bit longer. Good thing I'm not doing it with Azure. I'd get exactly one deploy in and then we'd all have to go. So until later today when they fix that. All right. App is up. Internal server error, which is great.

Let's see here. You all keep hitting it, which is great because it's just tailing endlessly. All right. What did I do wrong? Get, click, do, or index counter. Ah, hang on.

This is expecting an application variable or an instance variable that I don't have here. So we're just going to say push error. All right. I was trying to minimize Heroku deploys. This does not minimize Heroku deploys.

Oops. All right. I did say if my demo was failed that I would do an Irish jig. Is anybody going to hold me to that? So here we go. At the end, I have a very, very fragile demo.

So I might have to do the entirety of Raindance because that one has a lot of moving pieces to it. But we'll get to that in a second. And any questions? No? All right.

So I can tell you a story while this happens. So I'm actually a .NET developer by history in Python recently. Good, a question. Thank you for saving me from the story. Not for pusher.

And actually, not for any of these. Because they just use simple HTTP requests, they work with any web host or framework, essentially. Oh, repeat the question. Thank you. He asked if it works any differently between Azure, App Harbor, Heroku, or Amazon. And the answer is no. All right. So this is up now. And it's still not working.

All right. You can tell. I practiced this one 30 times. Too many. All right, let's go back to it. I'll give it one more chance to try to fix it. I don't know if you guys saw Rob's video yesterday.

I need the thinking step back from a moment video. See, the view was not tracked. All right.

One more time. Does anybody else have really bad self-esteem commit messages? It's like, why did you get into this business? Your mom wanted you to be a preacher. Maybe you should consider it. No, just me? OK.

I keep telling people I'm a horrible programmer. Nobody will believe me. They keep hiring me. Anyway, Rob believes me. Thank you, Rob. That's why we're friends. All right, if it doesn't work this time, we'll move on to the email demo, which I have the complete sample for here.

Discover that process type. You can do it. I think it's called continuous delivery because you're continuously waiting.

I'm beta testing jokes now because I have stall, right? I only had enough jokes for one or two deploys. Nope, that's local. Hey! All right. So does anybody else have this loaded yet? So if you start tapping or clicking on the number,

you can see this is distributed. This is all the events that are hitting your machine. So I'm glad that many people are clicking because later, we have to get to 100. So I know it will only take 10 seconds now. All right. So now let's take this push your messaging thing. I'm going to close mine.

You guys can continue to tap on that to no end if you want. I think I have more as much user engagement as Farmville now, so I can be rich. Actually, did anybody ever see that app that was just clicking and incremented a number? OK, never mind. I have too much free time. All right, so let's get back to email. So now what I want to do is I want to take it.

So I'm going to accept incoming emails, and then I'm going to write out all the messages on the screen from all the emails that you send. Now, I've done a lot of live demos in the past where I put people's real text on the screen, and I realize that's dangerous. But we're all going to be good boys and girls today. We're not going to say anything that's not safe for work or offensive to anybody, right?

OK, great. So what do I need to do? So I have a post handler here for email. And now what I need to do is when the email comes in, I just need to say, all right, pusher. Make a request on the demo channel. Trigger the email event.

And then I'm going to pass in some data. I'm going to say message. Actually, I just realized. No, thankfully, I think Ruby will save me here. I was like, we're going to get the first ever email-based SQL

injection attack probably. But there's no SQL. And like I said, Sinatra will save me from that. All right, so I think that looks right. And then I need a route to actually display the results. So I'm going to say get email.

I'm really bad at mixing between single quotes and double quotes. So I'm sorry. I even said earlier I was pedantic, but that's not the right word. Where did it go? Pusher API key equals pusher API key. And then we're going to return the index.

All right, so essentially what happens is post the request comes in. I'm going to trigger the email event, which is going to pass along the text in the emails that you send. So thankfully, while I upload this one,

I can go over here and distract you by configuring my domain to point to this application. So I'm just going to copy it from here really quick while this loads. So now I'm going back in and I'm going to say, any email sent to email party should be posted to this URL.

It hosts an URL. And we'll go back and see how that's doing. Did the other people send me email? Oh, nice. All right. Wait, I got seven of those. Oh, because you all went to that URL, didn't you? Yeah.

I'm going to be getting these for like months, like just endless NDC rocks. I will never forget how awesome this conference was. All right. So that is now up. And all right. So I'm going to say hi at email party. Oh, I got to pull up the viewer first.

Otherwise, it's not a very good demo. Not an application error. Yes. I live to work another day. And then from my email, hi at emailparty.com. And then say, remember, you all promised to be nice. Send. That goes out, makes a post request,

and I get a JavaScript error. Just like every good web app. Undefined. I must have passed the wrong parameter name. Somebody else sent in. There we go. Thank you. Let me refresh this.

Really, I have written code before. Data message. Oh, see the extra S right there? Get you every time.

Wait, where'd my browser go? Did anybody else see this when we came in today? Have you all seen this video? Oops, wrong one. That one.

Has everybody seen this Rube Goldberg machine? Well, I won't subject you to the whole thing. But there's something entertaining while we're waiting. So later on, I'm actually going to do a Rube Goldberg machine with six different APIs connecting them all together. So if you're in the overflow room,

you should come back in about 10 minutes. All right. This is also how I feel every time I deploy code. It's like somewhere off, this is happening, and then at the other end is a working website. All right. All right, here we go.

So somebody did a script tag in their email. Thank you very much. I knew that would happen, except I didn't account for it. So if I go back here to my email, I can be clever as well. I can say hi at script window dot close, send.

And I didn't do a script tag around it. Oh yeah, I did. Whatever. Well, you got the point. So let's just do a real one so you can see it working. I don't know if anybody else is out there still trying

to send email to my party, but hello. All right. So pusher, webhook, REST API could be sending messages. And we've got everything combined. So we've got about 20 minutes left. So I want to talk a little bit more.

That's the extent of my coding because clearly it went so well that I should do lots more of it. But instead, I should get back to my outline. So I want to talk a little bit about sort of what the API industry is, sort of like where it's going. But first, a couple tools that are really useful.

So hurl.it lets you make web requests from the browser. This was started by Chris Wanstroth and Leah Calver from now at GitHub. And Leah has got a couple different startups. I acquired it while I was at Twilio without asking for anybody's permission. It lets you basically do cURL with a nice user interface on it to make web requests. So another one was request bin. You saw that it lets you log sort of incoming requests

to a URL. This was made by a Twilio coworker. It's sort of a version two of postbin.org, which was sort of similar. And then another one that's really useful when you're debugging and working with web APIs is this service called local tunnel. And what local tunnel does is it takes any port on your local machine and gives it a public URL. So if you're debugging web hooks,

instead of having to deploy to Heroku every time, you can spin up local tunnel. And that gives you a URL. And you can use that as your webhook URL. And then it hits your local machine. So this is really nice in Visual Studio if you have the debugger because then you can have remote services hitting your application. And then you can actually debug it with real live data. There's another version of this show off IO and another one I found out today called tunneler

with no vowels in it, of course. So there's a couple of tools that would make your lives a lot easier if you start working with a lot of APIs. So now I want to talk about the future. And then I got the big demo at the end. The reason I really wanted to go work at If This Then That is because it's the culmination of sort of like the realization of all the great things

that APIs bring us. So If This Then That lets you connect all of these different services together because they all have APIs. And eventually If This Then That is going to have an API that lets anybody create a channel. So now any APIs are going to be able to talk to each other in the world. And that will be completely controlled by developers out there. So if you have a service and you want to make it so that the pictures on your service

automatically go to Dropbox, or if you have a social network and you want to let people post their Facebook things there but you don't want to build that, then If This Then That will allow that. But this is sort of limited to the fake world of our computer screens. This doesn't really interact with the real world. So there's a couple initiatives out there. They're sort of taking APIs and breaking them

out of the computer screen and really bringing them out into the real world. So the Pebble Watch is a Kickstarter project that just pre-sold $10 million in watches. What they want to do is they want to offer an API that allows anybody to post notifications to the watch. So it goes through your smartphone and then it goes to the watch via Bluetooth. However, this allows any cloud API now

to be on your watch at any second. So imagine you take that incoming email one and if one of your most important customers' emails into your support thing, you might want to know that. Instead of having to take your phone out and dig it out, you could get that notification right on your watch. Or in my case, anytime there's a new Pottermore book or something.

All right. So another case of this sort of creating inputs going the other way is this Twine project. This is another Kickstarter project. Essentially what this is is a sensor in a little box that's connected to Wi-Fi. So it'll sense temperature changes or moisture or vibration or noise and essentially make web requests

with that data anytime that happens. So now we can get input from the real world into our web applications as well. So we could have it say anytime it shakes a certain amount, tweet that somebody's broke into my front door or anything like that. So this is sort of like bridging the gap between this online world of APIs and the real world thing.

So I envision everything being an API. And there's no reason why when you scan your card at the hotel, why it shouldn't go off to their web application and be able to like, the logic whether or not it unlocks should be up to the hotel. Why do you have to buy another system for that? We already have good ways to communicate.

Or every time a door opens or every time a light switches on so you could track usage. I would love all of these things to be API powered and be able to get them in and have all of them work together. And so that's why I'm going to work at IFTTT. And IFTTT is really, really serious about working with sort of this offline stuff and is actually more, like really wants to get into that. And they've already announced that they'll be partnering with both Twine and Pebble to integrate with them.

All right. Overflow room. You should watch now. So if you have a laptop, I would really appreciate it if you helped. You would need to go to this URL. And if you have your speakers muted, turn them up. And if you get a security warning, just hit allow. I promise I'm not doing anything bad to your machine.

And then again, turn up the volume. So what I've done is I've written a Rube Goldberg machine that uses a bunch of different APIs. And like I said, this is really fragile. So this makes me super nervous because I've wanted to do this for a year in front of people. And it's just me at home doing it over and over again.

It's not very exciting. All right. So what I'm going to do is I'm going to kick this off by making a commit to GitHub. And then it's going to go through a bunch of services basically passing data back and forth. It's going to stop at one point while it waits for a reply from me via SMS. And some of the web hooks are not immediate real time. They take a couple seconds.

So I'll do the Irish jig again or whatever will keep you entertained. And when we get to the end, there's a special surprise. And all right. So first thing I need to do is I need to basically change a file and then go back over here. And I'm going to commit my changes.

All right. I'm going to now commit to GitHub. And I'm going to switch over to the browser. And it's going to start quickly. But I'll explain what's going on. So git push origin master.

All right. So it's waiting for the commit. As soon as the commit comes in, it's going to do the post request. So you can see there's the message that I put in the commit request. It's sending off an email to SendGrid. Now SendGrid got the message and sent a text message to Twilio. Twilio sent the text message to my Google voice number, which has now arrived. And now I need to reply to keep the chain going.

So I'm going to actually reply with a special string that I put in here so that you can't mess with this. And then some random numbers to get around Twitter's duplication check. So when I send this back, it's going to send the message to Twilio. Twilio is going to receive it and tweet what I just sent in the text message. Twitter now, I have set up a listener on the user stream,

and it's gone off and created a FogBugs ticket with the text of the tweet that I just sent out. Now FogBugs has created the ticket. Actually, if I go down here, you can see... Well, it didn't show up down there yet. But it did create the ticket, which I will show later. FogBugs is the slow webhook. Sometimes this takes up to a minute. So this is where I dance or sing or tell you or ask Joel Spolsky on video

why this webhook takes so long to fire. It does give you sort of like... It does make one point that sometimes webhooks don't need to fire immediately to be useful. Like, you don't necessarily need to know immediately that a ticket was created. So, you know, any time within 30, 60 seconds, or even 5, 10 minutes, can still be useful. And that wasn't enough BS-ing to make it through the delay.

But this will fire, I promise. I've waited many times through this, and it works every time. But this is where you're starting to doubt my ability and everything you thought was true about life and software and Spolsky and the Joel test and everything.

But I promise you, it's going to fire. No, really, it will. Since it got past... Twitter is the one that fails the most. Like, the streaming API doesn't always pick that up. So once it got past that, I'm pretty confident that once this webhook fires that we will finish. And then your computers are open and on this page as well.

I never even gave you the URL. Oh, my goodness. So you probably have time. You can still pull out your laptop and go to roob-status.herokuapp.com. Did you do it? Okay, good. Did you? Okay, we got a couple. Okay, great. See, I told you it would fire. All right, so everyone has their laptop open. Now you need to start clicking on Click Here,

because we need to get to 100 combined clicks before it's going to go to the next step. So that went really fast. All right, we made it! It worked! Oh, but it's not quite done. So I'm actually going to mute mine, and you should turn yours up.

So they're now connected via Twilio Client voice over IP connection. So in a moment here, when the Norwegian National Anthem finishes, which is a beautiful song, by the way. I've listened to it 40 times in the last three days. I've almost made up my own words to it and everything like that. All right, so they've got their audio up.

I'm going to go to a different page here, and I'm going to wait until that audio finishes. This would have been great with 100 laptops, just so orchestra and like tear in my eye would have been great. So they're almost done.

People on video probably can't hear, but there's at least three laptops playing it. And as soon as they're finished, which it's way shorter when you're not standing on stage. All right, so now that it's finished,

the people that are connected, I've dumped them into a conference room. So if I talk into my computer, you should hear it coming out of your computer. Can you hear that back there? Yeah, so that worked. So anyway, there's my Rube Goldberg machine for APIs. If you had that page open during that,

you can see all of the requests that were made throughout the process. And I'm really excited about the future of APIs, and I hope that makes you excited about them too. And that's all I have. Are there any questions? I can't believe that worked. I'm so excited. I came all the way to Norway to get that demo to work

from San Francisco, and it did. What was that? Yes, you can mute your computer now. Any other questions? All right, well, thank you very much.