01:37 - Greg Baugues Introduction

02:51 - Twilio

05:27 - Two-factor Authentication

13:42 - Implementing Security; Why Security is Important and Essential

27:26 - Twilio Use Cases

34:16 - IP Messaging

38:02 - TwiML

    Burner

42:46 - Using Twilio to Enhance Business

48:50 - Twilio’s Tech Stack

50:19 - Opt-outs and Phone Number Validation

52:45 - Lookup

55:46 - Developer Evangelism

  

Goodbye, Avdi. We will miss you <3
 Avdi's Newsletter

 

 Who wants to be the next Ruby Rogue? Submit your video.

 

Picks

The CHECKS Pattern Language of Information Integrity (Avdi)
Delegation (Avdi)
CaJohns Ignite Hot Sauce (David)
beach house (Coraline)
CocoRosie (Coraline)
The Misters of Circe (Sam)
DesktopServer (Chuck)
Advanced Custom Fields (Chuck)
Convert Post Types (Chuck)
Gravity Forms (Chuck)
MemberPress (Chuck)
SIGNAL Conference (Greg)

Special Guest: Greg Baugues.

 

Hey everybody and welcome to episode 258 of the Ruby Rogues Podcast. This week on our panel we have Coraline Ada Ehmke.

I knew you'd be here today.

David Brady.

Today on a very special Ruby Rogues, one panelist will not finish.

Avdi Grimm.

Hello from Tennessee.

We have a new permanent panelist, Sam Livingston-Gray.

Well, how did I get here?

I think there was an email involved.

Oh yeah, right.

[Chuckles] I'm Charles Max Wood from DevChat.tv. And this week we have a special guest and that is Greg Baugues.

Hello, everyone. I'm very, very happy to be back again. Thank you.

I know. It's been quite a while. I think the last episode you were on was the depression episode, if I remember right.

Yeah, that's right. It was just about two years ago.

And it was… it's been one of the episodes I think I've heard the most about from listeners when I

meet them. Several people would come up to me and basically say, “I don't know who that guy was but I didn't realize how bad off I was until I heard it and then talked to somebody.” So, it's made a difference I think for a lot of people.

That's really cool to hear. I really appreciate you all giving me the opportunity to come talk about that stuff.

Yeah. Do you want to introduce yourself really quickly since you haven't been on for a while?

Yeah, sure. My name is Greg Baugues. I serve on the Developer Evangelism team at Twilio. Twilio's based mostly in San Francisco but I am in Chicago. And yeah, so for those who didn't hear it a couple of years ago you may have heard my name from a talk I gave called 'Developers and Depression'. I've been doing that for a couple of years primarily in the Ruby community. And then I have a newsletter that I send out occasionally with links and resources on the topic at DevsAndDepression.com.

Cool. Well, we brought you on today to talk about Twilio. So, do you want to give people a brief overview of what is offered by Twilio? Because I think some people get the idea of phone but they don't really get much further than that.

Yeah, for sure. Most practically speaking, what Twilio can do for a Ruby developer is within about 10 minutes of signing up for an account you can send and receive a text message and place and receive a phone call in less than 10 lines of Ruby. So, it really, truly does feel like magic. It's an API that can make your phone ring. And Twilio's been around for about eight years now. And generally speaking, their goal is to bridge the gap between developers and the 150-year-old telecommunications industry. At least that's where we started. We've been doing some cool stuff in the last couple of years around IP messaging and video chat. But most folks probably know us because of the phone stuff. And the telecom system used to be say 10 years ago if you wanted to send or receive a text message or make a phone call you probably have to start by hiring a lawyer and then negotiating with all of the major carriers and then running a line out your office.

That's what I do for every one of my projects. I always start with a lawyer.

[Laughs] You probably don't need Twilio then. You'll be right at home there. And so, and they basically have just taken, done a lot of that groundwork, and give you an API to interact with the telephone network. And then just in the last year we've been offering IP messaging or chat crossplatform and then also video chat as well.

Yeah, that's interesting. I think the thing that I've played with the most is the text messages. I've played a little bit with phone numbers and phone calls.

I think text messages is probably the most gratifying way to get started. I think generally speaking developers don't like talking on the phone. And being a little programmatically send text messages and receive text messages is a ton of fun. And then once you realize you can do that, it tends to open up a whole bunch of fun hacks that you can throw together in an afternoon along with a whole bunch of interesting business cases.

Yeah. I think I built an app at one point using Twilio that basically you could text in and it would text you back and ask for an email address and it would sign you up to get the emails that we send out every week where you can get the podcast episodes. And of course it's out there and it's launched and if you have the number and the little keyword you can text in, you can actually make it work. But I haven't published it and it has some bugs in it. So, that's part of the reason. But it did work at least on my phone.

I think you're probably not the only one with a few unfinished…

Proof of concept Twilio apps living in their account.

Yeah.

So Greg, I am necessarily pretty security-minded. And I recently went through the 'Crash Override: So You're About To Be Doxxed' course and enabled two-factor authentication on absolutely everything. So, Twilio can be used. That's one of the use cases for Twilio is setting up two-factor authentication?

Yeah, that's absolutely right. There's kind of a cool story there. So, we realized a couple of years ago that a huge chunk of our customers were signing up for SMS so that they could implement two-factor authentication. And from cursory glance it should be pretty easy, right? Generate a random six-digit code, fire off a text message, listen for a text message to come back, check to see if it matches up. And then if it does sign them in. in practicality it is way more complicated than that.

You have to worry about encryption. You have to worry about is that code you're generating really secure. You have to worry about, can that code be brute forced. You have to worry about what happens if your user doesn't have access to their phone or doesn't have access to the cellular network.

There was a customer of ours that had started building a solution for this and basically wanted to be the Twilio for two-factor authentication. So, the idea being developers don't want to do all this other crap. They just want to get back to building the features that are unique to their application. And so, Authy started building these APIs for two-factor authentication. And last year, we acquired them and joined forces so their team is under the Twilio banner. And that's what I've been speaking on the most in the Ruby community over the last year. And the talk I give will do a live coding demo and will start with a Rails app that just has basic authentication, email/password, and then integrate two-factor authentication into it using Authy.

And it really just takes three API calls. There's one to register a user, one to send the token, and then one to verify the token. And then Authy also works. There's an iOS app, an Android app, there's a Chrome app. Then it also works over SMS. So, it just covers a ton of the bases so that you can implement two-factor authentication and have confidence that it's done securely and then have confidence that it's going to be updated as security vulnerabilities come out, and then get back to doing the things that you do.

Yeah, I think I went to a RailsConf talk where you talked about this.

Oh, yeah.

Last year.

Yeah, yeah. It was… yeah, so it was not 2015 yet. 2014. In Atlanta, right?

Yup.

Yeah, that was a good one. Yeah, if you want to learn more about it, it's Authy.com, A-U-T-H-Y dot com. You can also find it via the Twilio.com home page.

So, they did become the Authy of two-factor authentication?

The Twilio of two-factor authentication, yeah. And that's worked out super, super well for us. Because inherently part of communication most of the time when you're communicating you want to have some degree of confidence who you're communicating with. And so, verifying identity fits really nicely into Twilio's mission of just fueling the future of communications [there].

Well, especially where the web is so anonymous.

Yeah.

And also, where a lot of this stuff is mostly automated. So, authentication for example, it's automated in the sense that there's not a person on the other end flipping through a book to make sure that your username and password line up. And so, by having two-factor authentication it's nice to just verify for your financial app or your privacy-minded communications app, that the person who's getting in and getting access is the person who should be getting in and getting access.

Yeah. If you're listening to this podcast and you don't have two-factor auth enabled on at least your email account just hit pause and go do that. Because if you're like me, if you get access to my Gmail account you pretty much own my life. Everything is routed through there. And then like Coraline said, start going through, starting with banks, starting with everywhere else and just enabling it everywhere. Because how most of these huge hacks happen, and I think I just read this morning that Minecraft leaked seven million user details through another vulnerability, it's like every single week someone else is getting crushed by this stuff. And Slack got hit last year. And then the blog post that they released announcing the vulnerability, I think the title was something like 'Our Security Incident and Two-Factor Authorization Is Now Enabled'. And so, it was like there wasn't even a comma between something bad happened to us and the way we're solving this problem is with two-factor authentication.

And so, as developers I think we're probably rapidly getting to a point where two-factor auth is just considered the best practice. And we need to protect our users in such a way so that if their stuff gets compromised on another site, because most users to be honest are just using, they probably have what, like four passwords? Maybe three passwords? Maybe one password? And that's typically how these hacks happen is some site somewhere gets compromised. Now you have a list of seven million email addresses and passwords. And now it's just a for loop and they're just running through trying out all the different sites. And if you have two-factor auth enabled it's going to eliminate 99.9% of those attacks.

Yeah. The other end of this, and you kind of alluded to it but I want to be very clear about it, is the email. If I have access to your email address then I can go to Stripe or your bank and I can say, “Oh, I forgot my password.” I log into your email account because it's going to email me a link to reset it. I can go reset it to whatever I want so I can get in. And then I just delete the email so you never see it. And so, by having this on those areas where it's access to everything else, you definitely want it there.

There is a fantastic article by a guy named Mat Honan. It's in Wired. It's from a couple of years ago. And the title of it is 'How Apple and Amazon Security Flaws Led to My Epic Hacking'. So, this was from 2012. And so, the security flaws have since been fixed. But the… I'm just going to read a short… he does a better job saying this than I could summarize it. And so, this is just about, just a few sentences of text here but I think the magnitude of this attack is pretty amazing.

50pm, a password reset confirmation arrived in my inbox. I don’t really use my me.com e-mail, and rarely check it. But even if I did, I might not have noticed the message because the hackers immediately sent it to the trash. They then were able to follow the link in that e-mail to permanently reset my AppleID password. At 4:52, a Gmail password recovery e-mail arrived in my me.com. Two minutes later, another e-mail arrived notifying me that my Gmail account password had changed. At 5:02pm, they reset my Twitter password. At 5:00 they used iCloud’s 'Find My' tool to remotely wipe my iPhone. At 5:01 they remotely wiped my iPad. At 5:05 they remotely wiped my MacBook. Around this same time, they deleted my Google account. At 5:10, I placed the call to AppleCare. At 5:12 the attackers posted a message to my account on Twitter taking credit for the hack.” And this happened to him solely because his Twitter handle was M-A-T and these hackers on the other side of the planet thought it would be cool to own that Twitter account.

Oh, wow.

The best part of this is, well so he gets… well, let me talk about a couple of things. One, on that hard drive were all the pictures of his baby. So, I think he had a one-year-old daughter and they were not backed up to the cloud. And so, he would have lost all those. He was able to get all the data back from his hard drive by paying thousands of dollars to one of these data recovery services. But what he found out is that they used social engineering.

They called up Amazon and were able to add a credit card to his Amazon account without authorizing himself because what harm could that possibly do? Call back, use the last four digits of that cart they had just added as a way of verifying their identity to get their Amazon password reset. Once they logged into there you could see the last four digits of all of their credit cards, then he could use the last four digits there with Apple to regain access to his account there. And then use the Apple which was the backup email address for his Gmail to do a Gmail reset. And all of this happened in 10 minutes and they barely had to touch a keyboard and certainly needed no programming knowledge to make this work.

That's pretty amazing. You made a comment a little bit earlier about how a lot of developers, they just want to ship features. They don't want to deal with this security implementation stuff. And I'm definitely in that camp. But I think that there are some people in this industry who, that's a really appealing thing or maybe there are developers who are newer in their career and they might not understand why implementing your own security isn't such a hot idea. Do you want to talk about that a little?

Yeah, to the extent that I can because I am not one of those folks. And so, I'm sure that you're going to have folks listening to this who are way better on the cryptography and security side than I am. But I certainly fall more under the category of folks who just want to get back to shipping features and sleep well at night. But let's start. I think most people who have been doing programming for a while understand that it's hard to generate truly random numbers. And so, if you think about a six-digit code, how do you know for sure that that six-digit code is truly random and that the pattern that you're using there can't be guessed? I think there's also maybe even, there are just attack vectors that you might not even consider if you don't do this stuff professionally.

So for instance, I mentioned earlier can you brute force this thing? Sure, you can send over a sixdigit code but are you also building in the functionality to make sure that this gets reset? Is that token, does it expire after a certain amount of time? There's also benefits that you get from using a service that deploys this across thousands of sites because you can see and identify common attack vectors. So, if you see a ton of traffic hitting one of your customers and say, entering the code wrong a bunch of times, when that traffic starts hitting another one of your customers, then another one of Authy's customers, then Authy can say, “Hey, this is probably a malicious attack because it's coming from a similar bank of IP addresses.” You don't get that same safety of running with the herd that you do if you're just deploying and monitoring your own stuff.

And then I also think there are just the practical aspects of, back when I was working at a consulting company, we would deploy a feature to the client, get a check like, “Okay, that feature is deployed,” then we move onto the next thing. There's not always budget or time for maintenance when the new attack vectors or… like every few weeks it seems like we're finding a new vulnerability in OpenSSL or in Ruby or whatever it is. And so, do you have the bandwidth and the attention span to stay on top of all those and to be going back and fixing all of those security issues as they pop up? So, I think even if you have the knowledge and the technical expertise which I don't, you might not have the time or bandwidth to stay vigilant about it.

That's a good point. And so, I guess Authy is like an overall good solution for that sort of thing for the reasons you mentioned.

Yeah, yeah. That's what they do. We do have a bunch of those. The engineers that you mentioned, that Sam mentioned there, that care about this stuff and really nerd out on it, we've got a bunch of engineers who work there who do that and this is all they do. They're not shipping additional features for other things. Their job is to stay abreast of all the security stuff that's going on and to make sure Authy stays safe for the thousands of customers that are using it.

So, I'd like to make a general plea to developers who are listening. If you are collecting any kind of personal information whatsoever from your users, please enable the 2FA. And if Authy makes it easier for you, please use that. Because you cannot underestimate the damage that can be done even if someone gets an address, even if someone gets a phone number. So, please, please put it in place. Think about your users.

I think it's interesting that you bring this up Coraline with your plea just because I think a lot of us, we're going to get into this discussion of privilege here for a minute, but a lot of us just don't think about it because nobody's trying to hack my account. And I don't have to deal with a whole lot of garbage on the internet. But there are people that do. And because there are people that do, you talked about what to do if you get doxxed. And there are people out there that have a legitimate concern about this kind of thing because it's scary. And well, it's wrong and I think we can all agree on that. But by not thinking about it because “Gee, I don't have this problem,” or, “I'm not going to think about it because who does that ever happen to?” you need to get it in your head, “This does happen to people and it can lead to real harm for people.” And so, when we're talking about this we're talking about real life scenarios with real people who we've probably heard or talked to. And that's why we need this is so that we can protect those people. It's not just so that we can protect somebody's blog on the internet that their mom and their sister reads. But it's because as was illustrated with the article that Greg pointed out people can actually get this information and take the next step to hijack somebody's email address, to hijack their Twitter account, get their other personal information, maybe publish where they live, how to find them, tell people, “Oh, this person deserves to have these horrible things happen to them.” And who knows? It gets really, really dicey really quickly.

Yeah, it's a pretty scary situation. And I think that highlights the importance too for having diverse teams, having people who have different experiences from the more privileged developers. Because people simple don't think of these things because it's not on their radar at all. So, it's not malice. It's just not really understanding the issues at all.

Yeah. There's an interesting cross, just kind of dog-piling on this a little bit, I work at CoverMyMeds and we do healthcare. And we have PHI and PII. And we had security training. And they sat us down. They say, “Just so you guys know, we're handling the most lucrative target on the internet. Credit card information sells for about a dollar a pop. But PII or PHI is 10 bucks.”

PHI is Personal Healthcare Information.

Yeah, I'm sorry, yeah, Personal Health Information. PII is Personally Identifiable Information. And so, if you've got… we handle prior authorization for insurance so we've got your name and address and a medical procedure that you had or a prescription that you're trying to get filled. So, we've got the Venn diagram of vulnerability there. The comment I would make about 'just do something with your security', Greg you made a comment about you gain the advantage of running with the herd. And I think a lot of security people, and at CoverMyMeds we've got a fantastic security team. They really, our Ops and Infrastructure dev team, they take this stuff really, really seriously, which can lead to some intense interactions.

Because I'm on the developer side. Because my job as a developer is to introduce vulnerabilities. [Laughter]

And I actually really like having these guys there acting as my unrelenting conscience. And what I will say is there's a counter-intuitive thing that you think, “Well, if I'm running with the pack I'm also, I'm swimming with the same tank of fish in this barrel.” Authy is now a very big target. If we can compromise Authy, we can take out the whole herd, kind of thing. And that's a valid concern. So, if you decide that you want to dedicate a team to your security that's okay. But please, whatever you do, don't decide you're going to do your own security and then download a package and just install it and then forget about your security. Because now you have the worst of both worlds. You are neither swimming with the herd… you're not running with the herd but you're also not avoiding the 'I'm in the tank, a barrel of fish'. If you install WordPress and you look at your logs, you're going to see just script [inaudible] is running known exploits over and over and over against every WordPress blog out there. And if you're not keeping WordPress up-to-date you're in the same barrel. And if you're running your own WordPress site you're not running with the herd.

Developers have this, we have this thing that we do where we're like, “Oh, that's a hard problem. I better think about that for half a day and come up with my own solution.” And I see this time and time again and security is one of those areas where it's like, “Oh, I read a cool blog post on security and I want to write my own encryption algorithm now.” And it's like, no, just stop right there and rely on and trust people who do this for a living.

Yeah. Not only is security through obscurity not any kind of security. But if you try to roll your own, this is a very thoroughly well-studied area. And if you try to roll your own you are going to make one of five really common mistakes that are known. Like, if you try to roll your own you are going to make a mistake that they are expecting you to make. So yeah, just don't do it, kids. Just don't do it.

Well, the other thing to keep in mind, and this is something that goes back to the idea of we're all in the same barrel, and that is that if there is a leak in the barrel or if somebody finds a way to actually fire into the barrel so to speak, there are people out there who are part of Authy (I'm making an assumption here but I think I'm safe in the assumption). They have a staff of people because so many people are using Authy that will actually… they're keeping up on the latest exploits for the web.

Yes.

They're keeping up on the latest exploits for the different ways of implementing two-factor authentication. And so, if you're building your own then you're taking on all of that responsibility and it's nearly impossible to keep up with the state of the art of hacking systems like this. But if there's a team of people that are dedicated to it, sure there may be an exploit where somebody actually gets past the gate. But those people are going to be much more involved in keeping track of that stuff and will plug it much more quickly than you can.

I think it's reasonable to say that if you are a hobbyist Ruby developer you're going to have a hard time competing with someone who's a developer full-time. The same way, the folks who are trying to exploit these vulnerabilities do that full-time. They do that like it's their job. So, if you're trying to do all the other stuff you do plus also in your spare time keep up-to-date with security you're going to lose.

There was a startup here in Chicago that I was interacting with a little bit or I knew some of the people involved. And they were a team of junior developers that have just come out of a bootcamp. And they're like, “Oh, we have this great idea for an app.” And it involved interacting with government databases and they were storing Social Security numbers. Not only did they not have 2FA but they weren't even using encryption on the SSNs. So, this is the kind of, anything we can do to make it super drop-dead simple for people with little to no experience to enhance the security of their applications, I'm all for it.

We had Dan Luu on a couple of months ago and I love his article about the normalization of deviance, how broken practices become standard in software.

Yeah, that was a great episode.

And there's a line in there that, sadly I missed recording that episode and I'm totally kicking myself

for it, but the article has one line in it that turned my blood to ice where he basically says if you will not listen to these early signals – and by early signals I mean if you're listening to this podcast and you don't have 2FA and we're telling you to get 2FA this is one of those early, low-amplitude, leading signals that you need to be listening to – if you don't listen to these early leading signals then you will learn this lesson by getting hacked. That's the only other way to learn. So, you can pay me now or you can pay with your company down the road.

And if you're under pressure to be delivering features, maybe you're at a startup, think about the economic cost of causing your entire customer base to lose faith in you and lose confidence in your product. That's important.

Or think about the economic cost of a lawsuit. It's not uncommon for the people who build these things to get sued when they leak information, especially when you're talking about HIPA.

Yeah.

Or the health information.

Government fines for HIPAA are huge and they're per violation.

Yup.

Yeah.

The government is motivated, if you look… I had to read through the entire law of HIPAA a couple of years ago to work with a client, and if you read through the HIPAA laws there's a lot of stuff in there that says, our job is not to put you out of business. Our job is not to stop day-to-day operations, which is why they have the weird thing at the pharmacy. They say, “Please stand here for privacy.” They implemented that because there was no way to prevent people from overhearing the pharmacist talking to the client, and that kind of thing. And HIPAA said, we're not going to stop you from being a pharmacy. We're not going to stop you from working.

But if you then go on to read the rest of HIPAA it's very clear that what they're saying is when they start handing down a hundred thousand dollars per incident or 10,000 dollars per record of leaked information, and usually if you're going to leak information you're going to leak all of it right? You leak 10,000 records, congratulations. You just burned a hundred million dollars in fines. And the legalese is very clearly worded to say if you are a big company like GM and it's going to take you three months to rectify a PHI or PII problem, we're going to give you fines starting at day 60 or at day 30 that are like a million dollars a day. And if you're GM you can go, “Well, we can either accelerate our process or we can pay 60 million dollars in fines.” If you're a small business, HIPAA is basically saying, “If you're not willing to solve this problem before your 30 days are up we really don't want you in the business of handling other people's PII.”

I kind of want to change the topic here a little bit. We've gone…

We could talk about Twilio. [Chuckles]

Why are you here, Greg?

The security here is pretty interesting. But on a lighter note, there are a lot of fun things you can do with the Twilio APIs outside of Authy. I'm curious. What are some of the interesting that you've seen done with Twilio, Greg?

Sure. There is a magician named Doug McKenzie who's in New York and we hear this kind of story often. He discovered Twilio and he taught himself to code in PHP so that he could incorporate Twilio into his magic tricks. So, if you google Doug McKenzie. Just go to his website and you'll find a couple of videos, one where he's doing magic for LeBron James. And there's a couple that are really good but you'll see him do tricks, the standard magic tricks you might think of where he has someone pick a card. But then they text a number and they get back a picture of the eight of clubs. Or he might do the thing where it's like add your birthday and multiply it by your phone number or the last four digits of your phone number, whatever it is, text this number, and it sends you back your six-digit super-secret pen.

And so, he's amazing. I'm not sure when this is going to air. It might air too late. But we have a developer conference going on in San Francisco May 24th and 25th and we did it last year. It's called SIGNAL and he came and opened up the second day of the show for us and did this magic trick from the stage with 1500 people in the audience that involved the whole audience texting in this number that he had. And it was pretty amazing. And he learned to code just so that he could do this. It's super cool. There's another guy who's… May 24th and 25th.

There's another guy named Ryan Leslie. He's a hip-hop artist and producer. He built this thing called SuperPhone. So, he gives out his phone number at every single concert he goes to, every video. If you go to his Twitter, RyanLeslie, he has 500,000 Twitter followers, you can text him. And he basically built a lightweight CMS so that he can have a direct connection. He says that he has 500,000 Twitter followers and 40,000 of them have texted him. And so then, when you text him, he sells all his albums direct. He pulled all of his stuff out of iTunes. And so, when he has a new album coming out, he knows who bought his previous albums, who have attended his shows. If you text him… and when we were coordinating with… he's coming this week at the conference next month and sure enough, I just texted him 11 o'clock at night. And 20 minutes later this dude who's made music for Kanye texts back. He's like, “Yeah, I'd love to be there.” And it was amazing.

So, those are some fun examples. We have a lot of social good that's happened. There are some women here in Chicago, Rose and Genevieve…

I know them. I worked with them, mRelief is amazing.

Yeah, it's great. You want to say what they do?

They are basically a service, and correct me if I get this wrong. A lot of lower income people do not have access to desktop computers. They have access to the internet via their mobile phones. So, what mRelief is doing is making it possible to see what social welfare programs you qualify for with a centralized phone interface.

It's basically an SMS survey. You text this phone number and it runs you through a series of questions about your income and where you live and your family. And it will tell you what social programs in the city of Chicago you're available for. So, things like education, before school and after school programs that are sponsored by the city, things like meal assistance, things like utility bill reduction. They have helped thousands of people who don't have an internet connection at home, maybe don't have a desktop computer. But these days just about everyone has a cellphone. And even if you don't have a smart phone the SMS app is the only app that's installed on every single phone. No matter… a lot of phones don't even get email. But they all can send and receive text messages.

I wasn't aware of the SMS features that they had built out. That's really amazing.

Yeah. No, it's fantastic. They've done some really good… they're going to be speaking at SIGNAL too. And they've really helped the city in an incredible way. And they were graduates of, I believe The Starter League here which is a dev bootcamp like program. When they started working on this, they had been programming for months. They're not… but they just saw this need that needed to be solved and then figured out how to use text messaging to do it.

As far as fun use case, I'll give one more. Last year I taught my dog how to text me selfies. [Laughter]

I started playing… well here, let me back up even further. Our dog is two years old. A few weeks after we got her, I'm laying in bed and we had this light next to her bed that's from IKEA. It has a floor switch on it and you just stomp on it to turn the light on and off. And I was like, “Man, I really shouldn't have to get out of bed to turn this light on and off. I have a dog.” And so, we taught her how to run over, slap the switch, and turn the light on and off. And then after that I was like, “Alright, so I got this dog that can press a button. I wonder what else I can do with that?”

And I had just started…

What could possibly go wrong?

Yeah, right? [Laughter]

I had just started playing with hardware hacking. I had really no experience with that. I got an Arduino Yun which is an Arduino that also has a second chip on it that runs a stripped down version of Linux. And then it also has Wi-Fi connectivity. And so, I basically did the hello world of the Arduino world is blink. The hello world plus, plus would be press a button and make a blink. And this thing has a USB slot on it, too. So I was able to plug in a web cam. And so, my dog runs up, presses the buttons, takes a picture with the web cam. And then I did it originally in Python but you can run Ruby on this thing too, and it just fires off a really quick script that takes the image file that's stored on the chip and sends an MMS using Twilio to my phone. So, my dog can run up, press, and text me selfies. So, I was giving a talk on that quite a bit last year, too. And it was a lot of fun.

So, does your dog text you every two minutes?

If I gave her treats, she would. I kind of figured out she'll do just about anything for a treat.

But if there's no treat involved she tends to be not particularly interested.

That's really interesting. I trained my cat to lay around and sleep most of their day.

Wow.

That's a lot of work.

That's some advanced stuff right there.

Yeah, she's really good at it.

I don't have to give her any treats, either.

Wow.

You must be so proud.

She's better behaved than my dog, then.

So, I want to dig into there are a couple of other APIs that… we talked about text messaging and phone calls but what about the IP messaging and video chat? What exactly do those provide?

Yeah. That's a great question. So, Twilio's mission is not to send or receive a text message, place and receive phone calls. Twilio's mission is to inspire and equip developers to change communications, to change the way the world communicates. And obviously it doesn't take a whole lot of foresight to see that the world is moving heavily towards more IP-based messaging as opposed to SMS. SMS is going to be around for quite some time. But the adoption we're finally starting to see just in the last couple of years starts slow. And it's still growing. Usage is still growing. But the adoption is not growing as quickly.

And so, you have WhatsApp. You have Viber. WeChat is huge in Asia. And all of these have a similar issue of say Skype for instance. So, we've been able to have video chat for a really long time. Skype's been around for 10 plus years now. But in order for us to have this Skype call right now I had to connect, I had to know your username. I had to actually update the Skype client. And in the last few years there's a technology that was started by Google called WebRTC that allows peer-to-peer connections in the browser. And so, you can do video calls directly in the browser. So now, most of the time I use something called Talky.io which is you just go to Talky.io/Baugues and whoever meets there joins into a video chat together.

What Twilio wanted to do on the video side is make it really easy for developers to embed video into their existing apps. And so, instead of having to go to the standalone app that you could just add video into the apps that you're already building, and try to do the same thing with chat. So, most of the chat that happens over IP right now happens in these standalone apps. And what we want to do is give developers the ability to add chat, which again kind of like the two-factor authentication is more complicated than it initially seems at first glance. So, you probably think at first if you've ever done a WebSockets tutorial, typically the hello world with WebSockets is building a quick chat. But productionized… productionalized? I don't know. Production chat involves a lot more than just sending the message back and forth. You want to have identity management. You want to keep a chat history. Often you're going to want to have typing indicators. You have the concepts of different channels. And then you also have cross-platform functionality. So, you're typically going to want if you think like a Slack for instance you're going to want people to be able to interact with a desktop client and interact with iOS and Android apps.

And so, both the video and the IP messaging are a set of SDKs. So, JavaScript SDK for everything that you would do in the browser and then iOS and Android SDKs so that you can use one set of SDKs to deploy chat and deploy video in the apps that you're already building in the languages that you're already working in. So again, that you can just have that infrastructure taken care of for you and then get back to deploying the features that you're already working on.

That's interesting. And we've done episodes on JavaScript Jabber on WebRTC if you want to dig into a little bit more on that technology. But it's really, really fascinating.

There is some really cool stuff happening.

Yeah.

In the WebRTC world.

Yeah. JS Remote Conf also last year, not this year but last year, had a WebRTC talk. And he showed off, he talked to three or four different devices in his house in different ways using WebRTC. Some of it was video. Some of it was not. And it was really, really interesting. So, I'll put links to both of those in the show notes as well.

Yeah.

One of the things I saw on the Twilio readme that was really intriguing to me and is not really explained is TwiML. Can you talk about what in the world that is?

Yeah. For sure. This is probably not the best named thing that we've ever come up with. So, it's… we pronounce…

Is it TwiML?

Yeah, we pronounce it “twimmle”. So, it's Twilio XML. So, let's say that you signed up for a Twilio account right now. The first thing that you would probably do is to purchase a phone number. So, a phone number will cost you a dollar a month. You can find it in just about any area code. And I

don't know how many countries. Probably a hundred plus countries. That number is wrong so I'm just going to be super general. But it's all over the world.

You can buy a number through the Twilio app, right?

That's correct.

Or through Twilio API. And your documentation has you searching for a number with 'awesome' in it. So, can you actually search for phone numbers by word?

Yes.

Yes, you can.

I've done that. [Laughs]

That is so awesome. [Chuckles]

Yes, you can. You'll be hard-pressed to get anything more than three or four characters of your choice. It's not quite like domain names. We buy phone numbers in bulk from wherever the places that phone numbers are born. And then, so we kind of have what we have. But we have a lot and if you're looking for three or four letters together you can typically find that. \

And let me actually step back just a second and we'll talk a little bit about how Twilio itself works, the mechanics of it. When you then text that phone number or you place a call to that phone number Twilio makes an HTTP response or an HTTP request to your server somewhere. And so, it's just like you punched a domain name into a browser somewhere and then an HTTP request is made to that server somewhere. It says, “Hey, what do you want me to do?” And that server returns back some mix that typically HTML is involved or is included in the payload that comes back. So, what happens here is that Twilio makes an HTTP request to the endpoint you have set up as your messaging or your voice endpoint. And what it is expecting in return is TwiML which is just basically our fancy way of saying Twilio XML. So, it's XML that has a very specific set of primitives that instruct Twilio what you would like it to do. So, in the case of text message, the most common response is just going to be, you're going to see an open response tag and then an open message tag and then you'd have the body of the message that you want to respond with and then you close the message tag, close the response tag.

And so, in Ruby for instance whenever we'll do a five minute demo where we just get up on stage, we'll buy a phone number and we'll typically ask someone in the audience, “What's your area code? We'll buy a phone number.” And then just start with a blank Ruby file. And then in Sinatra just write up a messaging web hook and then it just basically kicks out some XML. We'll have everyone in the audience text that and they'll all get a response right there. And then we'll make everyone's phones ring, like initiate a phone call to everyone who just texted in. if someone calls that number you have to set up another endpoint for that too. And then the TwiML would look like, it might do something like dial where it just forwards.

So, one of the use cases that people use Twilio for is I don't know, last year we were considering buying a house. We didn't do it. But we were considering it. And so, I went to LendingTree.com and it asked for my info. And I had a hunch as to what was going to happen there. And so, I bought a Twilio phone number and I just set it up to forward to my cellphone and I gave them my Twilio number. And then once I was done getting those offers I just killed the forwarding. And there's an app called Burner app that uses Twilio to provide people for temporary phone numbers if they're selling stuff on Craigslist or whatnot. And so, that's…

Or dating.

Dating. Actually, eHarmony uses us for anonymous communication. So, same with Airbnb and Uber. So, when you're texting or calling whoever is on the other side of that, let's just put in air quotes “transaction” whether it's eHarmony or Airbnb or Uber, it's passing through Twilio numbers so that you can give out the number of the driver or the number of the other person that you're meeting on eHarmony without actually giving out their personal number. And then once that pairing has stopped, once that ride is complete or whatever, that number then gets recycled for future transactions. So, you're absolutely right. There's a huge, huge number of people who use this for what we call anonymous communications or also known as masked phone numbers. But to get back to your original question Coraline, all of that is driven by TwiML. It's all, TwiML is just the XMLbased instruction set by which you tell Twilio what you would like to do with that text message or that phone call.

So, I have some questions about your tech stack. But before I get into that, I actually have more of a business-oriented question. You've talked about some of the really high-profile uses of Twilio. And also some of the particularly unique ones. But I'm curious. I don't know. It's one of those things where when I think about it I think, “Oh, that's neat” and I might think of a few toy ideas. But I rarely make the connection to, “Oh, this is how I would use this to enhance my business.” And I'm curious. Are there some common ways that developers ought to be thinking, “Oh, this is a way that I could enhance somebody's business or my own business using these technologies.”

Yeah. That's a really good question. And you're right. A lot of the use cases I've thrown out were either novel or they were businesses that didn't exist pre-internet. So like, Uber, Airbnb or something. So, how does Twilio apply to more established or what we think of as old-school businesses? One of the ways that we're used most common is for what we call call tracking.

And so, if you think about… I wrote a blog post on this last year and I used the example Better Call Saul. I don't know if you all have watched the show or watched Breaking Bad or not. But if you watched Breaking Bad the lawyer on there, his name is Saul Goodman. And he runs these television ads and he has these billboards and he has ads at a bus stop. And it all says, his tag line is “You better call Saul.” Like if you get in trouble, you get arrested, whatever, you better call Saul. Prolific advertiser, Saul has a big problem though. He has no idea which methods of marketing or of advertising are yielding him the highest ROI, because when somebody calls his 800 number, he doesn't know if they saw it on a billboard, if they saw it on the bus stop, or if they saw it on TV.

And so, what folks will use Twilio for is they will buy again for a dollar a month, a different phone number for every advertisement that they run. So, you could run a different phone number on your Google Ads, ads on your billboards, et cetera. And then when a call comes into that phone number, before you would fire off that TwiML that says dial and connect this to our main phone number line, so everything will just pass right through to the receptionist or whoever is answering the phones, before you would do that you would increment a counter somewhere. And that would either be your own proprietary database you set up or what we'll often see is Google Analytics because that's where you're often tracking a lot of your marketing and advertising data anyway.

And so then, you can pull up and you can see, alright. The billboard cost us, I have no idea what billboards cost, the billboard cost us a thousand dollars a month and it generated from that phone number that's on the billboard and only on that billboard 200 phone calls. And our Google Ad campaigns generate this much. And then it will help businesses then whether they are internet or offline businesses, it will help them figure out where they should spend their next hundred dollars of marketing.

Another spot we'll often see is appointment reminders. Patrick McKenzie, I don't know if he's been on the show before.

He has.

He has? Okay. Patrick's one of my favorite people in the world. Go check out the stuff he writes if you haven't heard of him or whatnot. But he's fantastic. He has a business called Appointment Reminder which he more or less started because he discovered that Twilio was a thing. He was one of our earliest customers. He's probably our best unpaid developer evangelist. He has just spread the word and has said so many nice things about us over time. He's also speaking at SIGNAL and he spoke last year.

Appointment Reminder does exactly what you think it does. It sends out reminders for the appointments of doctors and massage therapists and dentists and plumbers. And you basically just go to his site and they sign up and then they punch in your appointment then you get a text message that says “We're coming out tomorrow at this time. Respond with 1 to confirm. Respond with 2 to cancel.” And when he was doing his business customer validation early on, he went in… And I believe the story is that he would go in and say, “Do you take walk-ins?” And they say yes and he'd say, “How much for an hour-long massage?” And they say 60 bucks. And they say, “Okay, how about instead of you giving me a massage, I'll give you 60 dollars and you let me interview you for an hour?” And he's like, “How painful is it when someone doesn't show up?” And they're like, “Well, it's just I lost 60 bucks. I don't get that time back. I can't schedule someone in that slot. And it's just one-eighth of my revenue for the day that I lose.”

And so, he built this thing and can demonstrate a quantifiable value. If one person shows up per month that would have cancelled, then it pays for what you're paying me. And I don't know exactly what his pricing is. But it's pretty easy to demonstrate the value proposition for that.

And one last thing I'll say is more generally speaking, email or open rates for SMS are… well, here. Let me say it. We started up a podcast a few months ago and it's called Twilio Radio. And we interviewed Ben Stein who runs our messaging team and I asked him. I said, what are the open rates for SMS? And he said all of them. And he's like, you don't really even open SMS. You just read them. Versus I don't even know what the email rates are or the open rates are for emails.

Probably 20% or so. It would be good I'm guessing.

It depends on the list.

Yeah. Very, very true. Very, very true.

And a good list can get 50% or more, but most don't.

And that's just opens. Not even people reading or clicking.

Yeah, or the call to action. So, any business that needs to communicate with customers, SMS is a pretty good way to do that. Now, different messages are more appropriate for SMS versus email and SMS is a very… it's perhaps the most intimate form of electronic communication that we have. So, it needs to be used very appropriately. But it is a fantastic way to quickly communicate with customers.

Nice. Those are great examples, thank you.

Oh, thanks for asking, Avdi.

Alright. So, I mentioned I was curious about your tech stack and I do want to ask about that. What are you using inside Twilio and more importantly what are you liking?

I'm going to give a disappointing answer and that is to say that I don't touch the tech stack. And I don't want to… I do know that the frontend of our side, so what you would touch if you hit up the documentation or if you were to hit the dashboard, that's run off of PHP. And I believe that was just what we started with eight years ago or so. As far as the actual internals that are used to route traffic to… actually, I do know that we have a Python Flask app which is, you can think of as being very similar to Sinatra on the Ruby side. They're very, very similar to each other. We have that, that helps route traffic as it comes into the API to all the internal services. We are, and the reason I know that is because we have a member of the API team giving a talk on that at SIGNAL. And then we are heavy, heavy, heavy users of AWS. Everything's on AWS. Jeff Lawson our CEO is a former product manager at AWS. As far as the languages that are used to route the traffic to the carriers, I can't speak with any kind of certainty to. So, I will avoid giving wrong answers there.

Magical gnomes in other words.

Magical gnomes, yeah, yeah. Carrier pigeons mostly.

So, I have another question related to this. My first project as a professional developer, so this is when I actually had the title developer in my job, we were actually building a system that connected with the phone gateways and sent text messages to people. And I'm not going to get into everything that the app did. But there were a lot of rules we had to follow. So, the carriers have different codes that you have to be able to send in like QUIT or STOP in order to stop getting text messages. Or there were a couple of other ones. I don't remember what they all were. Does Twilio just handle all that for you automatically?

Yeah. So, the best practice is that you also implement it. But we do handle that. So, if you text STOP in all caps to a Twilio phone number you will no longer get text messages from that phone number. If you text start back to that number then it opens up the pathway again back to you. We'll still send a notification to your app that that came through. So, you should also as the developer be looking for that and then unsubscribe them from your list and update your database accordingly. But if somebody finds out that, if you're out there, we actually launched a new project last year called Lookup which is super fun to play with. Just go to Twilio.com/lookup and you can punch a phone number in there. And it will tell you if it's a mobile or a landline. It will tell you the carrier that it's on and we just a few weeks ago launched, you can pull up caller ID information from there as well. Then there's also an API for it.

So, one of the big use cases for that is phone number validation. So, if somebody say punches a phone number into your form you can validate that A, is it probably formatted, B, is it a legit number, and then C, is it a landline or is it a cellphone that can receive text messages? And based on that you would decide how your app is going to communicate with the. But one of the reasons I mentioned that is that one of my favorite games these days is whenever I'm out and about, I'm in the subway and I see an advertisement for some new on-demand service or whatever that has a phone number on there and I go and punch it into Lookup and I see that it's a Twilio number, and that's always very encouraging and a lot of fun to see. If you ever do that and you're getting texts that you would prefer not to get, go look and see if it's a Twilio number. If you text STOP then you will stop getting text messages from there. Even if the developer hasn't implemented that.

Since you brought it up…

Sorry, go ahead.

You brought up lookups which reminded me. I was asking a coworker of mine if there was anything that they might like to ask somebody from Twilio. We actually use Twilio in one of our apps to send text messages back and forth to our customer's customers. And apparently… I don't use it, like I didn't write most of this code myself, but apparently the lookups feature has a different API endpoint and maybe a different client library. And it seems like there's maybe a really interesting organizational story behind that. I wonder if you can speak to that at all.

Behind the lookups?

When something comes out in a different endpoint and with different client libraries that tells me that maybe there's a different [tiger] team working on it or something like that.

No, that's a very insightful question. And I think that it speaks to the evolution of Twilio over time. So, when Twilio first started eight years ago – and I wasn't around, I just started two years ago – I believe all we did was voice. So, you could place and receive phone calls programmatically. A couple of years after that we added SMS. And this is all a RESTful API and it was all the same API. Over time we've added more and more products. And you can imagine that as you add more and more features to a set then that means more teams working on a shared codebase. It means documentation gets really tough. It means that even the dashboard that users interact with which if you signed into your Twilio account and visit your dashboard about two weeks ago it was a mess. And it had been that way for a little while because we had this dashboard that had more or less started six or seven years ago then we added features and features and features to it, which is great. But then it got more and more complicated.

And so, one of the big things that Twilio's been doing over the last year is starting an un-bundling process. So, there are customers who will use something. So, it's called SIP. And so, you can imagine you could use SIP to run Twilio to power the phone that's on your desk. But if you're just doing that, you don't need a lot of the advanced Twilio functionalities, right? So, you don't need all of the stuff that TwiML offers you. You might not need to record phone calls. You might not need to be able to also send and receive text messages from that phone. But we were still charging you as if you did. And you can imagine how that goes through a lot of stuff. There are certain customers that need certain features. They don't need everything.

And so, one of the thing's Twilio has been doing is un-bundling a lot of our services from one another. And I think Lookup is probably one of the first things that you've seen along those lines where it is no longer going to the same RESTful, the same API that's sending and receiving text messages was coming from. And then similar stuff is happening with Twilio IP messaging, with Twilio video. And you'll see more and more of that. So, that's a really, really… again, that's a very insightful question. And the general answer is un-bundling.

Greg, I have a…

Cool, thanks.

I have a question for you. Like, we spend some time talking about developer career paths. And a lot of developers of course end up in management. A lot of developers end up in the guru or mentor role. And you have ended up in a developer evangelist role. So, I'm really curious about how you got there and if you miss coding.

That's a really great question. Chuck and I had briefly discussed maybe coming back and talking more about evangelism in a different episode because it's a huge topic. First and foremost I still got to do a ton of coding. So, Twilio is a highly technical product. We call it an invisible product. It's an API. If we as developer evangelists and there are about a dozen of us on our team don't maintain technical credibility then we can't serve this community. So, if I'm at a hackathon and I haven't written code with the API recently then I can't help that developer build their app in 24 hours. I can't go to 1871, the big co-working space here in Chicago, and help our customers or the startups there and sit down with them and work on that.

So, I don't code obviously as much. I do 20 to 30% of my time is coding now. And it tends to be on a lot of smaller projects as opposed to diving deep into one codebase. What I do get to do though is work a bunch of different languages. So, in the last two years I've been able to write… like I came into this job as mostly a Rubyist who had done PHP for quite a while but hadn't really written PHP for five years. And in the last two years I've published blog posts or written code on stage in

Ruby, Python, PHP, doing the Android stuff. I've started playing with Android, do quite a bit of JavaScript. And so, it's given me great exposure to a lot of different languages. At the last hackathon I was at, I got to actually in 24 hours help debug apps that were written in each one of those languages as well. And so, that part has just been fantastic.

I would say that my breadth of programming knowledge has expanded. But I probably do sacrifice a little bit of depth. All of the developer evangelists on our team have come from some sort of developer background where they had great depth. And so, just about everyone has worked as a professional engineer before. And that's just by nature of the fact that Twilio is a highly technical product. There are certainly developer evangelists for other products out there who don't need to be as technically competent in order to serve as the developers there. But it just happens to be so for Twilio. And thanks for asking the question. I love talking about that stuff. And I will just say, if you enjoy writing, if you enjoy speaking, and you enjoy coding, developer evangelism for the right people is just a fantastic job. And I'm always happy to chat about it. I really do believe that I stumbled upon what's the best possible job that I could have.

Alright. Well, let's go ahead and get to the picks. But before we do there's something that Avdi wanted to say to our listeners.

Hey. So, five years ago when the Ruby Rogues started I was so excited because it was the podcast about Ruby that I wanted to listen to and so excited that it existed. And when I was first asked to come on, I was even more excited. And when I was asked to join it was a dream come true. I was over the moon. And it's been wonderful. But all good things must come to an end. And I've realized lately that it's time for me to pour my time into other things. And so, this is me saying goodbye for now at least. I'm retiring from the Rogues. Hopefully I will be back from time to time. And I just want to say it's been fantastic. All of the current and former panelists are not just my copanelists but they have become my friends. And I've been just thrilled with the wonderful community that's come together around this show. So, thank you everyone who's listened and thank you Chuck for putting this together through all these years. And that's about it. If folks want to keep up with my doings as I've mentioned a few times on the show, I do have sort of a newsletter that I publish from time to time. And you can find that at SIGAVDI.email. And you know, I'm out there on the internet. But bye, everyone. Thank you so much.

Avdi, you're going to be sorely missed.

Yeah.

Yes.

Thank you very much. I've learned so much from you on this podcast over the years.

Oh, thank you.

We kept trying to put that off. But it had to happen, I guess.

Avdi, I just want to echo that, too. I guess perhaps as the representative of the listeners who's [on this] right now when I was getting into Ruby five years or so ago, I just learned so much from you. And it was a total pleasure to be able to meet you at some conferences later on. And you're just so calm. You do such a great job of presenting complex technical topics in a way that's humble and just very accessible. And you were a real inspiration for me and I'm sure thousands of other people as they got into this language, and I think just an awesome representative of the Ruby community as a whole too. And so, thanks for your service to the community there.

Well, thank you so much. Thank you.

One other thing I want to bring up before we went to picks is as you may have noticed Saron has not been on for a while. She's just been really busy with her job and with CodeNewbie which she actually does on the weekend, crazy enough. So, we're looking for that new person voice to also come join the show. We're going to do something very similar to what we did about three years ago, four years ago. It's going to be I guess Ruby newbie number two. If you are a new or new-ish programmer to Ruby or new or new-ish programmer I should say and you're learning Ruby then what we would like you to do is put together a YouTube video telling us about yourself and explaining why you would like to be on the show. And there will be more details up at RubyRogues.com/ruby-newbie. And I will put every spelling of newbie I can think of in there so that you can just get it. But yeah, put the YouTube video together and then post a link in the comments. And we will do what we can to review those and then we'll probably do another episode, bring some people on to talk, and then probably select somebody from that group to join us and help us have the perspective of somebody who's coming to this brand new.

That is an awesome idea.

And with that, I guess we'll get to the picks. Avdi, do you want to start us with picks?

Sure. So, this is something I may have picked before but it's been on my mind lately and I just wrote a blog post about it. There's this very old, well old in terms of our profession anyway, paper that Ward Cunningham wrote called 'The CHECKS Pattern Language of Information Integrity'. And it's basically a pattern with a lot of experience and deep thought about dealing with user input in a humane way and a sane way. And it gets into a lot of subtleties that people don't often think about when they first start to take user input. And particularly if you're dealing with user input and you're thinking about validation I think there are some really important concepts in this paper. So, it's very worth going back and looking it up and reading it through maybe once or twice. I think it can help your programs.

The other thing I'll pick is probably also something I've picked before but it's also been on my mind lately which is delegation. It's not a particular thing but just the concept of delegation. I've found again and again that it's true that when you think that the things that you do nobody else could possibly do them and you could never delegate them you're always wrong. And you're always limiting yourself by thinking that way. And it's not something that I can just learn once. I'll learn it once and I'll delegate some things and then I'll move on and find new things that I think that only one person can do and then realize that I'm limiting myself that way.

And I think as programmers we have an extra special block to this because not only do we think, “Oh, I'm the only person that can do this,” but if you think that maybe I shouldn't be doing this repetitive task all the time, the next thing we think is, “Oh, I'll automate this with a script or with a program.” And then we sink a few days of frenzied effort into it and realize that it's more complicated than we realized and it's not worth the effort and then we give up. And we go back to doing it manually. So yeah, there is stuff in your life that you can delegate. Look for it and then expand what you're doing in the free time that you free up. That's it.

Alright David, what are your picks?

I've just got one today. People have been pinging me on Twitter saying, “When are you going to do another hot sauce pick?” And so, I have one. While I was out in Ohio doing my on-site with CoverMyMeds I walked by a CaJohns fiery foods store. And I did not know who CaJohn was. And I feel embarrassed about this because he's one of the inaugural inductees into the Hot Sauce Hall of Fame which just started last year. But he's one of the most award-winning hot sauce makers in the world. So yeah, it's really, really good. When I say CaJohn it's spelled like Cajun but with John, JO-H-N. So, C-A-J-O-H-N. I'll put a link in the show notes. The sauce that… I actually got three and I'm actually afraid to open the other two. So, when I build up my nerve I will have some more hot sauce picks.

But for now, the first one and the coolest one of the three is called Ignite Hot Sauce. And it's got red savina habanero chilis which were the hottest chili pepper in the world until 2006 when the ghost pepper came along. By the way, if anybody's keeping track listening to this show the ghost pepper is not the hottest pepper in the world. It hasn't been for about four years. There's a new kid on the block that's over two times hotter than ghost peppers out there called the Carolina Reaper. And no, I'm not trying one of those anytime soon. But the Ignite sauce is diluted down until… it's hotter than jalapeños but it's definitely, I can't find a Scoville rating for it. I would say it's probably between 15,000 and 45,000 Scovilles. So, the extract sauces start at about a hundred.

And the interesting thing is when you take red savinas which are about half a million Scovilles, when you dilute them down you don't get a cool sauce. What you get is a… or you don't get a warm sauce. What you get is a very cool sauce that's flavorful that has these bright little pinpricks of intense heat that just flash and then kind of go away. And so, this is a really, really good sauce. I've tried it out in soups and in tacos. And you can use it by the drop in a soup and it doesn't change the flavor very much. It does have lemon and garlic in it so you want to use it in salty foods. And you can if you're brave use it as a “table sauce” (what they say). And I just tried dripping it on a taco yesterday for the first time and it's quite the ride. It's absolutely fantastic. And I'm probably heading back into another bout of hot sauce addiction. [Laughter]

As a result. So, this will get the endorphins going. So, Ignite Hot Sauce from CaJohns Fiery Foods. And that's my whole pick.

Alright. Coraline, what are your picks?

So, like a lot of developers, I listen to music while I code. And the music I listen to I think in a way, in a subtle way, influences the code that I'm writing. And I have music for when I'm being contemplative and music when I'm trying to be productive and so on. So, I have a couple of music picks. The first is a band called Beach House. I hate the name. They're an American dream pop band from Baltimore. Only two members, vocalist and organist Victoria Legrand and guitarist Alex Scally. Legrand's vocal style is reminiscent of Nico. You've probably heard Nico with Velvet Underground. Influences include This Mortal Coil and Cocteau Twins so it's very dreamy, very background-y. You can listen to it and it's not going to distract you from what you're doing. And their most recent release is 'Thank Your Lucky Stars'. It was released last year and it's really, really good.

My second pick is another duo, this time sisters Bianca and Sierra Casady. And their band is called CocoRosie. They're best described as new weird American or sometimes called freak folk. Freak folk's a genre of folk music which uses acoustic instrumentation but it chooses elements of avantgarde music, baroque pop, and psychedelic folk often featuring uncommon sounds, strange lyrical themes, and unusual vocal styles. So, CocoRosie incorporates elements of pop, opera, electronica, and hip-hop into their music. They typically release a new album every two or three years. I got familiar with them from their 2004 recording 'Noah's Ark' which is a classic. But 'Heartache City' which was released this November is also very good. So, Beach House and CocoRosie for your coding music pleasure.

Alright. Sam, what are your picks?

I just have one today and it's also a music pick. I guess it's actually more like a pick and a half. So, you might not guess this if you ran into me just at a conference wearing the usual jeans and t-shirt but my musical tastes run a little bit goth. When I was 18 a friend of mine gave me a tape by The Sisters of Mercy and I loved it instantly. And I was…

Yay.

Right, they're great. And I was tweeting about them, the band and the friend, recently. And later I noticed that my tweet had been favorited by an account with an unusual name which is how I learned of the existence of The Misters of Circe who describe themselves as a gender nonconforming Sisters of Mercy tribute band. So, they're in London and I'm in Oregon and I'll never probably actually see them perform. But just knowing that such a thing exists just brings me joy.

And that's my pick.

Alright. I've got a couple of picks here. Some people may be surprised to hear that the last few weeks I have been spending a little bit more time in the code. I have been working in WordPress and PHP. And the reason is that…

That doesn't count.

[Laughs] I know, right? So, I went to MicroConf and I went to… I had a code… or a retreat, not a code retreat, with my mastermind group. You can listen to us on Entreprogrammers.com. We actually release our meetings as two to two-and-a-half-hour [laughs] podcast episodes. Anyway, while I was down there Derrick Bailey who does WatchMeCode.com or .net, sorry. If you're into JavaScript, go check that out. He talked me into having a look at WordPress again. I'd kind of given up on it. And it turns out that I can actually do most of what I want to do in WordPress and it will save me a whole bunch of time and effort getting what I want on DevChat.tv by switching back over to WordPress and then having some customizations done as opposed to doing a whole bunch of custom Rails work. So, I've been working on switching it back. So, I've got some picks related to that.

The first one is DesktopServer. If you want to have an XAMP stack, XP in Mac OS, set up then DesktopServer just does it for you. And so, you can get a WordPress site if you're doing any kind of WordPress development set up pretty quickly there.

A few other picks that I'm just going to throw in here. Advanced Custom Fields, if you want to add fields to your posts in WordPress. It's very handy. I also imported a whole bunch of stuff and had to convert different custom post types. And there is a plugin called Convert Post Types. That's also very handy. And then just a few other things that I'm using to get the work done. One is Gravity Forms and the other is MemberPress. And I'm really, really liking those. They're doing a lot in the way of collecting feedback. I'm hoping to be able to use that to collect more feedback more regularly from the website and get a whole lot more input on what we're doing. I'm also setting up a more streamlined or regimented, both kind of, way of getting show recommendations and turning those into episodes. So, working on that as well. I had a long talk with [Kyle] Davis who incidentally I'm talking to in about five minutes on The Freelancers' Show. But yeah, so a lot there. MemberPress is member access and it's pretty awesome as well. So, lots of picks. I'll have links to those in the show notes if you're doing WordPress stuff or have a WordPress site. And yeah.

Chuck as a developer aren't you obligated to write your own CMS?

That's what I actually have been doing for the last year and a half.

Okay. You get to hold onto your credentials then.

And it's… anyway, it's just turned out that I was able to replicate in about a week to two weeks' worth of full-time work spread over about four weeks but I was able to replicate what we did in a year in about a week and a half by customizing WordPress. So, if that's the kind of productivity I can get out of it, then I feel like I have to switch back so that I can spend more time doing the show stuff and less time doing the flailing about doing development stuff for the shows, if that makes sense.

Greg, what are your picks?

First pick, bit of a plug. As I mentioned earlier we're putting on a conference. It's called SIGNAL. It's May 24th and 25th out in San Francisco. We're going to have about 2,000 developers there. We're going to have over a hundred speakers. And it's all about the future of communications. So, if you are currently a Twilio customer or a Twilio developer we're going to have a bunch of folks from Twilio, developers who make Twilio talking about Twilio best practices. We got folks coming to talk about WebRTC. We've got people coming and talking about bots which if you've opened up Hacker News in the last couple of months you've undoubtedly seen a bunch of stuff about bots. It seems to be one of the hottest, I hate that word hottest, but one of the most popular topics these days in the tech world. So, it's going to be awesome. We had it last year. And it was just a ton of fun. And we'd love to have you there. I'll set up a promo code. Punch in Rogues100 when you register and we'll give you a hundred bucks off the registration there. And if you want to hear some of the speakers, you can check out the podcast Twilio Radio. And we interviewed a bunch of the speakers who are going to be speaking there.

Second pick would be Open Sourcing Mental Illness by Ed Finkler. If you all have listened to my talk or are interested in depression, mental health amongst the tech community check out, it's OSMIhelp.org. Ed gives a fantastic talk and has been doing it longer than I have about how mental illness affects the tech community. His site has a ton of resources for both employers and developers. He runs a survey every year and you could see the results there. But Ed is just a fantastic guy. He goes by funkatron on the Twitter.

And then real quick, I started watching the TV show Billions a couple of nights ago. If you have Amazon Prime you can get a 30-day free trial of the Showtime stuff which is what I'm doing to watch it. And I'm pretty sure I'm going to get through all 12 episodes pretty quickly. It's been a lot of fun. And that's it.

Alright, Greg. If people want to follow up with you, see what else you're working on, know what Twilio is up to, what do they do?

Yeah, for sure. You can find me @greggyb on Twitter. G-R-E-G-G-Y-B. You can find Twilio @twilio everywhere. And I'm also gb@twilio.com. And you can email me anytime. And then I have a newsletter DevsAndDepression.com where I send out some stuff about mental health.

Alright, sounds good. We'll go ahead and wrap up the show. Thank you all for coming and we'll catch you all next week.