April 24, 2015

Artificial Solutions, a virtual assistance (VA) solutions provider, has inked a deal to provide its technology to the Dutch state lottery, Staatsloterij. While a lottery might be an unusual use case for VA, what really separates the agreement from the pack is the company’s VA technology itself. The 14-year old company bases its VA solution on […]

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

In the pantheon of tools it takes to operate and maintain a farm, a RESTful API is probably not high up on the list. But, Simon Huntley is showing small farm owners how to grow their distribution network, and land new customers with Twilio’s API.

Huntley grew up on a farm in southwestern Pennsylvania. By the time he went to college to study Computer Science he was deeply versed in what it takes to run a farm, and the business challenges farms face.

Simon saw farms struggling to find people interested in buying their produce, meat and other offerings. They didn’t have the tools to build a website for themselves, and their business was suffering for it. Simon took matters into his own hands and founded Small Farm Central, a one-stop shop for farms’ online needs. Through SFC, they can easily set up a website, an online store, and manage customer communications via Twilio SMS, all without touching a line of code.

“I’m hoping to help bridge the gap between small farms and their customers using technology,” says Simon. Twilio SMS is a key tool he uses to help farms establish personal relationships with customers buying from their farm share, or visiting them at farmer’s markets.

The hour before a farmer’s market, families are making the critical call on if they’ll go or not. Small Farm Central helps farmers capitalize on that critical window through Twilio SMS and MMS. When customers opt in to the farm’s text message updates, they’ll get pictures of what the farm is selling an hour before the farmers market, encouraging them to come down and buy some great food.

“People let farms and farmers markets into their lives in a different way than they would larger brands. Text messaging helps cement a personal relationship,” Simon added. “Opt in rates are really high, we have text to join features so they can join the mailing list easily.”

Simon sees more and more farms adopting SMS outreach, and hopes that Small Farm Central will be a de facto tool farmers use to keep their farm up and running.

Learn more about Small Farm Central here.

Small Farm Central Gives Farmers A New Tool To Drive Business, Twilio’s API

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 23, 2015

In 2001, maroon was a color. Now it’s a band. When you read the word maroon, think it, hear someone say it, your brain autocompletes it to Maroon 5. The pop-rock six piece has spent more than a decade topping the Billboard charts. When Maroon 5 set out for their latest tour, they had the support of coconut water brand Vita Coco to fuel them — and their millions of fans.

Vita Coco put the call out to Maroon 5 fans to send selfies to their Twilio-powered number for a chance to win a trip to Barcelona, and see Maroon 5 play live. With the help of Twilio, and CRM Text, Vita Coco was able to scale their campaign to the size of Maroon 5’s gigantic fanbase.

Vita Coco got the idea for the selfie campaign before Maroon 5 went on tour. They knew that the campaign would be popular and looked into getting a short code that could scale to their demand. But, provisioning a shortcode can take months, and Vita Coco did not have the luxury of that amount of time. They contacted CRMText to get their idea off the ground and ready for tour.

“One of the big advantages of our platform is that for clients that need rapid response and don’t have 2-3 months to get their own shortcode, we can fill that need very quickly,” said Stan Bradbury, CEO of CRMText. CRMText used a shortcode, powered by Twilio, to ship a prototype of the application to Vita Coco within days their request. “It was great, the handoff was seamless,” added Stan.

InStoreMaroon5Just in time for the tour, the campaign was live in arenas across the US. At each Maroon 5 concert, Vita Coco plays a 30 second clip encouraging concert goers to send selfies to the Vita Coco shortcode to be entered to win a trip to Barcelona.

Vita Coco also launched a selfie campaign at retailers across the nation. They posted promo point of sale materials like photo-standees and signage in stores. They added a call to action encouraging people to take a selfie with the display to enter to win a trip to Barcelona and see the band play live. The call to action worked. Many consumers entered and Vita Coco saw a notable lift in sales.

“It’s been fantastic on all fronts. Our retailers are posting displays, our fans are engaging and our sales are up in participating chains in the months we’ve been running these campaigns.” said Jessica Qussar, Culture Marketing Manager at Vita Coco.

Vita Coco concluded their campaign as the North American leg of the Maroon 5 tour as the band played their final show of tour in Anaheim, CA on April 6th, 2015.

Vita Coco Connects Maroon 5 With Fans Using Twilio MMS

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 22, 2015

CraigWalkerCraig Walker’s career in entrepreneurship started from the sidelines. In the mid-90’s he was a securities attorney, advising startups how to survive and not get sued in the “nuclear winter” that fell over the Valley after the dot-com bubble burst. Not many people were rushing out of a stable career and into the post-bubble burst wreckage, but Craig was.

In 2001, Craig made the foray from legislation into the startup world. He joined a company called Dialpad that by all accounts was a sinking ship. There’s little pressure to succeed aboard a sinking ship. There’s also a sizable challenge to keep it afloat. The combination attracted Craig. After Dialpad raised 68 million in 6 months and spent over 80 million in 18 months, Craig set out to bring them back from the brink, while getting his feet wet leading a company.

“It was like operating on a corpse. had the company died, no one would have blamed me,” Craig says with a knowing laugh. He’s aware of his gallows humor, and nonetheless continues onto making a poignant observation. “Near death experiences teach you to be super focused. When some Dialpad marketing people asked me, ‘Should we spend $40,000 on this marketing campaign?’ I said ‘NO!’” This was a hallmark of the strategy Craig used to turn Dialpad around – what he calls “depression-era” tactics. “We want to make the product amazing, not worry about blowing millions of dollars to design an office,” he says.

As you can probably guess from his law degree and MBA, Craig is a pretty driven guy. When he wants to make a product amazing, odds are he’s going to do it. When he finds his product niche, he’s going to stick with it. At Dialpad, he made a groove in communications technology and stuck with it.

[Catch Craig Walker’s keynote at Signal, May 19th-20th in San Francisco]

The MBA in Craig cites communications technology as the perfect market. The entrepreneur in Craig relishes the challenge to change an industry whose old guards have done a fantastic job at neglecting user experience, and new technology. When Craig founded UberConference he was surprised that so many customers were used to such a terrible conference call experience, and that their previous experience was standard fare. “It shocked me that the conference call was the same in 2012 as it was in 1982.”

UberConference was the seed that developed into Google Voice, probably the most famous product that Craig’s worked on. It was a herculean effort, but one that was made easier by Craig’s passion for communications. “I like communications because every person on the planet is a consumer,” he says. “It’s easy to work on something that you’re passionate about, even if it’s something that you have a problem with.”

Craig still has a problem with communications technology, because he knows it’s not perfect yet. Communications is a gift that keeps on giving, there’s an opportunity to improve it. It’s a perfect fit for me because it’s evolving. It’s evolving with the web. Legacy guys don’t get it. It’s a perfect opportunity for people who also understand the telecom side of things and understand the power of the internet.  That combination is powerful.”

Craig knows his combinations. He’s based his career on them: legal savvy and entrepreneurial spirit, sinking ships full of ripe opportunities, telecom’s potential and the internet’s power. But, there’s an new combination he’s looking forward to. There’s a slate of software-centric entrepreneurs who are using technology like WebRTC to change the way we communicate. Craig’s hopeful that they’ll focus not on bringing telecom out of the past, but into the future.

Where Every Person on the Planet is a Consumer: Craig Walker Follows His Passion For Communications

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

It’s hard to punch in the correct conference PIN when you really want to punch your phone in its face. Sure, you’ve prepared for the meeting. Your agenda is rock solid. You’re ready to drop the phrase “let’s take this offline” on anyone who eats up too much conference time. But you can’t prepare for the PIN. When you’re already blood curdingly mad from your four previous unsuccessful attempts to enter the 14-digit PIN, you might not kick off the conference call with glee.

Callr knows your pain, and they’ve built an easy, Twilio-based service that automatically calls you directly before your meeting and connects you through to your conference call. Don’t worry, you do not have to enter the PIN number or even remember when to dial in. They do that programmatically so you don’t have to look into cracked screen replacement after you get off your conference call.

Callr CEO Mike Endale will readily admit that Callr’s magic isn’t calling you before your meeting. Twilio does most of that heavy lifting. Callr’s genius is getting you into the meeting without you lifting a finger.

Conference call PINs are all apples and oranges. From platform to platform each PIN is proprietary. Mike and his team took these conference call meetings constantly. The team  grew increasingly frustrated grappling with each proprietary system and being late to meetings because they couldn’t find the key code he needed to enter. This is where they got the idea for Callr.


The team couldn’t find a service that acted as a common denominator or universal key to get you into conference calls, so they built one. “We’re a bunch of nerds. We figured we’d move quickly and get this solved,” Mike says.

The hardest part was writing the universal key, the algorithm to connect all the conference platforms. It’s Callr’s secret sauce that powers their whole service. The Callr MVP was built in eight days and then rolled out the world after extensive beta testing.

“Twilio’s a great tool, it was easy to build on it. We spent more time thinking how to build it, than building it on Twilio. It’s really amazing how the API is structured,” says Mike.

After their mobile app was featured on Product Hunt and TechCrunch, their user base started growing like wildfire. While it was hard for Mike to find a common denominator to connect conference platforms, it was quite easy to find and capitalize on a common hatred of conference PINs.

Learn more about Callr here

Callr Eliminates Conference PINs for Good: Don’t Punch Your Phone, or PINs Anymore

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 21, 2015

Let’s face it: passwords are a liability. If a password is easy enough to remember it’s probably not secure. This leads to using applications such as 1Password to manage very secure passwords for us. It’s not an ideal situation but it works. It works right up until major websites get their databases hacked. Chances are someone has seen one of your beloved passwords before. Take a look at haveibeenpwned.com if you don’t believe me. If you’re in the clear, you’re quite lucky. Passwords are a flawed security solution on their own. Do we even need them at all?

Ricky Robinett recently wrote a blog post detailing how to build a passwordless authentication solution using PHP with Laravel. He was inspired by the Cover app’s implementation of this idea to get rid of passwords. In this post we’ll build a cross-platform mobile frontend in Xamarin that uses the authentication method from Ricky’s post. Xamarin is a platform for developing mobile applications using the C# language. We’ll be using a feature of Xamarin called Xamarin.Forms which allows us to write our user interface in a shared project. This shared project will generate UI for iOS, Android and Windows Phone from the same source. Once complete, your iOS, Android and Windows Phone applications can use this technique to remove passwords from the login workflow.


To follow along with completed code I’ve prepared this Github repo for you.

How Does the Backend Work?

This post will focus on building a cross-platform frontend that performs logins against a very simple backend as described in this tutorial. PHP isn’t an obvious first choice for a C# developer so I’ve ported that backend to work on ASP.NET MVC. The backend has the following endpoints:

  • /user/validate/ – POST requests to this endpoint with a phone number validate that a user account is associated with that phone number and send a verification token.
  • /user/auth/ – POST requests to this endpoint with a token validates that the token is correct for current session.
  • /profile – GET requests to this endpoint will return some super secret data. This endpoint can only be accessed after a user has authenticated.

Since we’re focused on the frontend and Ricky already did a great job of detailing how the process works, reading his tutorial is highly recommended. The .NET version provided above is heavily commented and matches up with the endpoints built in that post.

Setting Up Our Xamarin.Forms Application

Let’s get started by creating a new Xamarin.Forms application. There are two options for creating a Xamarin.Forms application and the difference is in how they share code. If you’re curious about the differences between the two options, the Xamarin documentation has a great explanation. If you want to support Windows Phone you’ll need to use Visual Studio to create the application. We’ll use the “Blank App (Xamarin.Forms Portable)” option to create our application and name it PasswordlessLogin:


A Xamarin.Forms Solution consists of one Portable Class Library (PCL) that will hold our shared UI code for the application and a platform-specific project for iOS, Android and Windows Phone. Note: Windows Phone support requires the project to be created and built from Visual Studio. We’ll work exclusively in the PCL project which is shown in the following screenshot:


If the Packages node under your project says it has updates like the screenshot above this means there is an update to Xamarin.Forms available. Right-click the Solution and click Update NuGet Packages. If you’re using Visual Studio, right-click the Solution and click Manage NuGet Packages…. Click the Update node in the list and then click Update All:


Now we’ll add some NuGet packages to the project. The packages we need for our application are:

  • Microsoft HTTP Client Libraries – adds support for the HttpClient object we will use to make requests to the backend from our app
  • Json.NET – to parse the JSON results that are returned by the backend during the authentication process

To install a package, right-click on the Packages node in the PasswordlessLogin project and select Add Packages… Search for the package name in the search box and add it by clicking the Add Package button as shown below:

Xamarin Studio:


For Visual Studio, right-click the Solution and click Manage NuGet Packages for Solution… and add packages as shown below:


With these packages added we have all that we need to start building our application.

Can I Have Your Number?

The passwordless authentication process starts by sending a POST request with the user’s phone number to the /user/validate. The first thing we need to implement is a screen for the user to enter this phone number. A screen is called a Page in Xamarin.Forms and there are two ways to create them. One way to create a page is using C# code. Open up the PasswordlessLogin.cs file  in the main project and you’ll see the following code in the App class constructor (if you’re using Visual Studio, this file may be named App.cs):

// The root page of your application
MainPage = new ContentPage {
    Content = new StackLayout {
        VerticalOptions = LayoutOptions.Center,
        Children = {
            new Label {
                XAlign = TextAlignment.Center,
                Text = "Welcome to Xamarin Forms!"

This is what the code-based API looks like for creating UI. In our application we will use the second method for creating UI: XAML. XAML (eXtensible Application Markup Language) is a markup language that allows you to create your UI using a declarative syntax. Though the tooling support is minimal at this point, in the future XAML will allow Xamarin.Forms to have great tooling for creating UI so it’s good to invest some time learning it.

Right-click on the PasswordlessLogin project and select Add->New File… (Add-> New Item… in VS) and add a Forms ContentPage Xaml (or Forms Xaml Page in VS) named PhoneNumberPage:


This will create two files: PhoneNumberPage.xaml and PhoneNumberPage.xaml.cs. The former will contain our UI markup and the later will hold the code that works with the objects in our UI. Open PhoneNumberPage.xaml and replace its contents with the following markup:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             Title="Enter Your Phone Number"
  <StackLayout VerticalOptions="Center" HorizontalOptions="Fill">
    <Label Text="Phone number" HorizontalOptions="Start"/>
    <Entry Placeholder="+15555551234" HorizontalOptions="Fill" x:Name="PhoneNumberEntry"/>
    <Button Text="NEXT" HorizontalOptions="End" x:Name="NextButton"/>

This markup specifies that the content of our page will be a StackLayout that fills the screen and centers its contents vertically. Anything added to this layout will stack vertically on top of each other. Inside of this StackLayout we add a Label, an Entry, and a Button. We provide an x:Name for the Entry and the Button so that we can refer to them from the codebehind file (PhoneNumberPage.xaml.cs). This is all we need to do to layout the UI for the PhoneNumberPage. However, if we launched the application at this point we wouldn’t see this page because we haven’t set it as the main page for our Xamarin.Forms app. To do this, open up PasswordlessLogin.cs (or App.cs in the Visual Studio template) and replace the App class constructor with the following code:

public App()
    // The root page of your application
    MainPage = new NavigationPage(new PhoneNumberPage());

This code creates a NavigationPage, which will allow us to move forward and backwards through pages in our app, and sets the root page for the navigation to be an instance of PhoneNumberPage. At this point it’s a good idea to test to make sure our UI is setup properly by running the application. Pick a platform-specific project of your choice (PasswordlessLogin.iOS, PasswordlessLogin.Droid or PasswordlessLogin.WinPhone) and set it as the startup project by right-clicking on the project node and selecting Set As Startup Project. Run the application (either on device or in a simulator) and you should see the following screen:


You’ll be able to enter a phone number in the Entry field but nothing will happen if you tap NEXT because we haven’t written any code yet. Let’s do that now. Open PhoneNumberPage.xaml.cs and add the following using statements:

using System.Net.Http;
using Newtonsoft.Json;

Next, we’ll add a field for an HttpClient object:

HttpClient client;

Add a line to the constructor to hook up the Clicked event for our NextButton:

NextButton.Clicked += NextButton_Clicked;

Finally, add the event handler for the button:

private async void NextButton_Clicked(object sender, EventArgs e)
    client = new HttpClient ();
    var content = new FormUrlEncodedContent(new[] 
            new KeyValuePair<string, string>("phone_num", PhoneNumberEntry.Text)
    var result = await client.PostAsync ("https://*** Your backend URL***/user/validate", content);

    if (result.StatusCode == System.Net.HttpStatusCode.OK) {
        var definition = new { Success = true };
        var response = JsonConvert.DeserializeAnonymousType (result.Content.ReadAsStringAsync().Result, definition);

        if (response.Success) {
            DisplayAlert ("Phone Number Valid", "You entered a valid phone number!", "OK");
        else {
            DisplayAlert ("Phone Number Invalid", "You entered an invalid phone number, try again.", "OK");
    } else {
        DisplayAlert ("Backend Problem", "Did not receive successful response from backend.", "OK");

The event handler creates an HttpClient instance. Next, it creates a KeyValuePair containing the phone number entered in the PhoneNumberEntry field to be passed as form encoded content to the backend. Then it makes a POST request to the /user/validate endpoint and checks the result for a Success value of true. Make sure to update the URL in the PostAsync call to your backend’s URL. For now we just display a popup on success or failure since we haven’t created the next page yet. Run the application and test with your phone number (make sure to use the format ‘+15555551234’). If you get the valid alert and a text message with a token is sent to your phone, you are ready to move on to the next step.

This Game Requires Tokens

In the previous step we were sent a token via SMS. To complete the authentication process we need to allow the user to enter that token in the next page of the application. Let’s create the token entry page now by adding a new Forms ContentPage Xaml file to the application called TokenPage. Open up TokenPage.xaml and replace the contents with the following markup:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             Title="Verify Token">
  <StackLayout VerticalOptions="Center" HorizontalOptions="Fill" Padding="10,0,10,0">
    <Label Text="Token" HorizontalOptions="Start"/>
    <Entry HorizontalOptions="Fill" x:Name="TokenEntry"/>
    <Button Text="NEXT" HorizontalOptions="End" x:Name="NextButton"/>

This markup should look very familiar since it’s almost identical to our previous screen. The only real difference is that the Entry field accepts a token instead of a phone number on this page. Let’s work on sending that token to the backend for verification. Open up TokenPage.xaml.cs and add the following using statements:

using System.Net.Http;
using Newtonsoft.Json;

Then add a field for an HttpClient object to the TokenPage class:

HttpClient client;

Replace the constructor with the following code:

public TokenPage(HttpClient myclient)
    client = myclient;
    NextButton.Clicked += NextButton_Clicked;

This time we are passing in an HttpClient instance to the page instead of creating a new one. This is because the backend uses cookies and we want to ensure that we use the same session when making the token request. Now add the NextButton_Clicked event handler:

private async void NextButton_Clicked(object sender, EventArgs e)
    var content = new FormUrlEncodedContent(new[] 
            new KeyValuePair<string, string>("token", TokenEntry.Text)

    var result = await client.PostAsync ("https://*** Your backend URL ***/user/auth", content);

    if (result.StatusCode == System.Net.HttpStatusCode.OK) {
        var definition = new { Success = true };
        var response = JsonConvert.DeserializeAnonymousType (result.Content.ReadAsStringAsync ().Result, definition);

        if (response.Success) {
            DisplayAlert ("Successful Auth", "You have authenticated successfully!", "OK");
    } else {
        DisplayAlert ("Backend Problem", "Did not receive successful response from backend.", "OK");

This code is also nearly identical to the previous page except this time we are passing a token value to the /user/auth endpoint for verification. Make sure to update the URL in the PostAsync call to your backend’s URL If Success is true we’ll display an alert indicating success. In a real world application you would probably want to navigate the user to the protected part of your application. One last thing we need to do is replace the Alert in PhoneNumberPage with a navigation to the TokenPage on a successful phone number entry. Edit the response checking in the NextButton_Clicked handler of PhoneNumberPage.xaml.cs to contain the following:

if (response.Success) {
    await Navigation.PushAsync (new TokenPage (client));
else {
    DisplayAlert ("Phone Number Invalid", "You entered an invalid phone number, try again.", "OK");

The highlighted line creates a new TokenPage passing in the HttpClient object and pushes it on the navigation stack for the app.

At this point the entire app is ready for testing. Run it on your favorite platform and test it out. Enter your phone number and hit NEXT. Then on the next page enter the token you receive and hit NEXT. If all goes well you should see an alert message indicating success:


Next Steps

Shout it from the rooftops, the password is dead! Or at least, it can be now that we’ve built a passwordless authentication solution that works on all three major mobile platforms. What could we do to improve upon the solution built in this post:

  • Create a registration page to create new users
  • Provide a backup authentication method in the event the user doesn’t have access to SMS
  • Implement a voice solution to provide the token in addition to SMS
  • Build a profile page for the user that they can only access once they’ve successfully authenticated

I’m really excited to see what kind of things you are building with Twilio. Feel free to reach out to me at any time via email at brent@twilio.com or hit me up on Twitter @brentschooley.

Passwordless SMS Authentication Using Xamarin

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

ThinkVoice gives businesses the communications tools they need to create exceptional customer experiences. ThinkVoice CEO Brian Coyle knows that something as simple and powerful as making a phone ring can be difficult to do at a large scale. That’s where ThinkVoice comes in. To ensure they’re giving their customers reliable and scalable communication solutions, ThinkVoice uses Twilio.

After the launch of Twilio’s TaskRouter, ThinkVoice added a new tool to their tool belt that enables them to manage traditionally difficult aspects of call center data like agent state, queue information, and more.

In the following post, Bryan Coyle shows how to build a Salesforce powered call center with Twilio’s TaskRouter. Read the original blog post here.

Building A Salesforce Powered Call Center

This is a beginner’s guide to implementing an omnichannel call center directly into your Salesforce CRM using Salesforce Open CTI, Twilio TaskRouter and Twilio client.  The source code for the solution is available here. The tutorial is aimed at developers looking to build a call center within Salesforce or just looking to learn more about TaskRouter.  If you just want to check out the end product you can deploy it to Heroku straight away.  If you aren’t a developer but want to learn more give us a shout and we can give you a demo.

If you want to bring phone calls into your Salesforce CRM you are, in the best case scenario, integrating a stand alone cloud based call center product with prebuilt connectors, or at worst integrating an on premise legacy PBX through multiple layers of integration.  In either case you are managing your call center across multiple systems leaving you with a management headache that is extremely costly and error prone.  The following tutorial aims to solve this headache by reducing dependence on third party solutions and leaving as much configuration in Salesforce as possible.


The demo demonstrates the ability to handle multiple channels of communication using Twilio TaskRouter to manage a single queue of communications coming from different channels.  This has been a real struggle as point solutions are only able to handle one or two communication channels and few support SMS as a channel.

Brief Overview the Technologies Used

The tutorial is built on the fantastic demo of a Salesforce embeddable ACD using Twilio Client by Charles Oppenheimer of Twilio.  Many thanks to Charles for sharing that demo.  We have simply taken that demo and inserted TaskRouter to handle the distribution of calls and addition of text messages.

  • Salesforce Open CTI -Salesforce Open CTI is an open API to allow third party CTI vendors to connect telephony channels into the Salesforce CRM interface.  In our demo we use Open CTI to house our soft phone and drive the click to dial/text functionality.  The demo requires no plugins or installed software thanks to the design of Open CTI. For more info see the developer guide.
  • Twilio ClientTwilio Client is a WebRTC interface to Twilio.  In our demo we are using the javascript library which gives us an API and connection to Twilio to receive the call within our Salesforce browser delivering the call via WebRTC.  Twilio client also gives us the ability to control the call via our soft phone.
  • Twilio TaskRouter TaskRouter is the queue and state machine that we have our Salesforce users connect to through the Open CTI soft phone.  We route all of our calls and texts through TaskRouter which manages the queueing of those  communications.  TaskRouter also monitors the state of our Salesforce users sending them the calls and texts as they become available.  What differentiates TaskRouter from traditional cloud or on premise phone systems is it’s completely API driven so we can place all administrative functions within Salesforce.

Getting Started – Part 1 – Phone Calls

First I highly recommend going through the original client-acd project from Charles as he covers all the basic setup including Twilio setup.  Our README covers the additional setup steps of configuring the necessary TaskRouter components.  At a high level we have replaced any code that was managing agent state or call queueing with TaskRouter code including removing all the Mongo DB code.  Mind the twilio-gem version.  The TaskRouter stuff is in after 3.15.  The rest of the post is going to cover the implementation of TaskRouter.

 Call Routing With TaskRouter

Lets start with routing incoming calls to TaskRouter.  In our Sinatra app we are going to change the /voice action to send the call into our workflow via Twiml.  This will immediately route our incoming call into the queue that is now managed by TaskRouter and the workflow we defined.  With that we now have a call in queue waiting for agent.  Very simple!

post '/voice' do
  response = Twilio::TwiML::Response.new do |r|  
    r.Say("Please wait for the next availible agent ")
    r.Enqueue workflowSid: workflow_id

Lets now hook up the agent state.

Salesforce Agent State Handling

Thanks to the work done in the original project it was really easy to plug the agent into TaskRouter.  As the softphone loads up within the Salesforce browser the softphone.js code was already pulling the agent id from the Salesforce API and registering as a Twilio Client.  Once we have a Twilio Client established we then go to register the agent with TasksRouter.  Much like registering a Twilio Client we need to get a token from the server with the proper permissions. In our code we pass the Salesforce user id in an ajax call so we can use that to match to the correct worker defined with TaskRouter.

$.get("/workertoken", {"client":SP.username}, function (workerToken) {
    SP.worker = new Twilio.TaskRouter.Worker(workerToken);
    var activitySids = {};
    // For this demo we assume basic states to map to the existing Ready/Not Ready so we will
    // take 1 ready and 1 not ready event
    // In real app we would make an interface with dynamic state drop down and map them here
    SP.worker.fetchActivityList(function(error, activityList) {
      var activities = activityList.activities;
      var i = activities.length;
      while (i--) {
        if (activities[i].available){
          SP.actvities.ready = activities[i].sid
        } else {
          SP.actvities.notReady = activities[i].sid

On the server we use the Twilio REST API to create a client to TaskRouter. With the REST API we can loop through all the workers that are defined for our Workspace, find the worker that corresponds to our salesforce agent and generate a token for that worker. We return that token back to the client side where our javascript function instantiates a worker via the worker.js library.

## If a workers is defined with the client name it returns a token for the TaskRouter worker
get '/workertoken' do
  client_name = params[:client]
  if client_name
    @trclient = Twilio::REST::TaskRouterClient.new(account_sid, auth_token, workspace_id)
    workertoken = nil
    @trclient.workers.list.each do |worker|
      logger.info worker.friendly_name
      if worker.friendly_name == client_name
        worker_capability = Twilio::TaskRouter::Capability.new account_sid, auth_token, workspace_id, worker.sid
        workertoken = worker_capability.generate_token
  return workertoken || ""

Worker.js is the javascript SDK that gives us the ability to receive work from the queue and gives us the ability to manage agent state. In this example we register for the activity.update callback which will let our client know anytime this agent changes state and when it does we update the UI. Worker.js also allows us to retrieve a list of activities or states that an agent can be set to. Each activity (or state) is either Available or Unavailable meaning they can take work or not. In this demo we assume one activity is available and will store the sid of one Available activity and one Unavailable activity. We use these sids to set the agent state later.

// callback for TaskRouter to tell use when agent state has changed
SP.functions.registerTaskRouterCallbacks = function(){
  console.dir("Register callbacks");
  SP.worker.on('activity.update', function(worker) {
    SP.functions.updateStatus("", worker);
    console.log("Worker activity changed to: " + worker.activity_name);

So we now have a call in queue, and a salesforce agent able to register to the queue and manage their state. Lets see how work gets distributed to our agent.

Routing Calls to the Salesforce Agent

Back when we setup our inbound call handling in client-acd.rb /voice we simply redirected the call to the TaskRouter Workflow with Twiml. Because we did this there is a little magic baked into TaskRouter we can take advantage of. First lets understand how TaskRouter routes work. The call came into Twilio and was directed to a workflow. The workflow is aware of workers (agents) who have attributes that the workflow can use to determine who should take that work. In this demo the workflow is acting as a simple queue knowing who has been idle for the longest. When we log into salesforce and click the Ready button Worker.js tells TaskRouter that our worker/agent is available. TaskRouter assigns the activity (the call in this case) to the agent. The workflow is configured to POST that assignment to our Sinatra app at /assignment. When the app receives that POST we simply tell TaskRouter to dequeue the call to the agent’s Twilio Client ID which is configured on the worker’s attribute

{“contact_uri”: “client:salesforce_login_id”}

#######  This is called when agents is selected by TaskRouter to send the task ###############
## We will use the dequeue method of handling the assignment
### https://www.twilio.com/docs/taskrouter/handling-assignment-callbacks#dequeue-call
post '/assignment' do
  raw_attributes = params[:TaskAttributes]
  attributes = JSON.parse raw_attributes
  logger.info attributes
  from = attributes["from"]
  logger.info from
  assignment_instruction = {
    instruction: 'dequeue',
    from: from
  content_type :json

Wrapping Up

TaskRouter has really simplified our code as we don’t need to manage agent state. We still keep a websocket connection and polling to push real time stats up to our soft phone giving our agent the number of logged in agents and number of items in the queue. We use the TaskRouter REST API to get that info.

## Thread that polls to get current queue size, and updates websocket clients with new info
## We now use the TaskRouter rest client to query workers and agents
Thread.new do
   while true do
     stats = @trclient.task_queue_statistics(task_queue_id).realtime
     qsize = stats["tasks_by_status"]["pending"]
     readycount = stats["total_available_workers"]
        msg =  { :queuesize => qsize, :readyagents => readycount}.to_json
        logger.debug("Sending webocket #{msg}");
     logger.debug("run = #{$sum} #{Time.now} qsize = #{qsize} readyagents = #{readycount}")

In the next part of this demo we will add text message routing to our Salesforce Call Center. Stay tuned.

Learn more about ThinkVoice here

Building A Salesforce Powered Call Center with Twilio TaskRouter

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 20, 2015

In a moment of outrage with UK mobile networks, I recently released a small app that you could use to send and receive Tweets using SMS and Twilio. In the next couple of posts I want to dive into the code and show you how I built it in only 62 lines of Ruby. We’ll cover setting the application up, webhooks and sending Tweets in this post. Then in part 3 we’ll see the Twitter streaming API and Ruby’s eventmachine working together to send notifications from Twitter.

If you want to build this on your local machine you’re going to need your Twilio details and a Twitter application. You can find all the instructions on how to set them up correctly in part 1. If you haven’t already got those bits go grab them now.

If you want to follow along with the code instead of building it yourself, you can find it all on GitHub.

Got everything? Great, let’s see what’s going on.

Application Setup

I’ll start with a confession: when I said the whole app only took 62 lines of Ruby I might have skipped over the supporting parts of the app. We’ll need to create a

for our dependencies:

$ touch Gemfile

Then add the following to it:

# Gemfile
source "https://rubygems.org"

ruby "2.2.2"

gem "sinatra"
gem "rack"
gem "twitter"
gem "thin"
gem "twilio-ruby"

group :development do
  gem "envyable"

I’m using Ruby 2.2.2, the latest version. The app is then built with Sinatra as our application framework. Rack underpins Sinatra as an interface between the web server and the framework. The Twitter and twilio-ruby gems are for interacting with their respective APIs. Thin is our web server, I’ll discuss why I chose Thin in a later post. Finally, in development I have envyable for loading config into the environment. Install all of this with:

$ bundle install

Speaking of envyable, we need to setup a config file for all those Twitter and Twilio credentials that we collected in part 1.

$ mkdir config
$ touch config/env.yml

Add the following to env.yml and fill in the gaps with your details.

# config/env.yml

You’ll need to format your phone number in the E.164 style. You’ll also want to surround the number in quotes so that the yaml parser doesn’t decide it’s an integer. As an example, if my number was 07799123456 (a nice fake UK mobile number) I would write:

MY_PHONE_NUMBER: "+447799123456"

We’ll also need a

file, this will allow us to run the application using any Rack based server rather than the default WEBrick. As we saw in the
, this is because we intend to use Thin.

$ touch config.ru

Add the following:

# config.ru
require "bundler"

disable :run

require "./app.rb"
run Sinatra::Application

The file does some very basic things, it requires Bundler and then the dependencies listed in the

disable :run
is a Sinatra command to disable the default web server, WEBrick. We then require the application file and the last line is a Rack method to pass the application to the web server and start it.

The final part of our setup is to create the file in which we’re going to write the rest of the application.

$ touch app.rb

In the application file we need to include our config. Add these three lines to the top:

# app.rb
configure :development do
  Bundler.require :development
  Envyable.load("config/env.yml", "development")

Now let’s get on to our first feature. This shouldn’t take us long, we’re going to send a Tweet from an SMS.

Tweeting With a Text Message

What we want to achieve here is a way to send an SMS message to our Twilio number and have it post a Tweet for us. Under the hood this looks a bit like this:

You send an SMS, Twilio notifies your app, your app gets the message, your app updates Twitter.

You send an SMS message, which Twilio in turn sends on to your application via a POST request, known as a webhook. When the application receives that POST request it will use the Twitter API to update your status. First we build the request handler that receives the Twilio webhook and posts to Twitter:

# app.rb
post "/messages" do
  twitter = Twitter::REST::Client.new do |config|
    config.consumer_key        = ENV["TWITTER_CONSUMER_KEY"]
    config.consumer_secret     = ENV["TWITTER_CONSUMER_SECRET"]
    config.access_token        = ENV["TWITTER_ACCESS_TOKEN"]
    config.access_token_secret = ENV["TWITTER_ACCESS_SECRET"]
  content_type "text/xml"

When the application receives a POST request to the

endpoint it updates Twitter with the Body of the message. We then return a blank
tag to let Twilio know we don’t want to do anything more with this.

I’m not so happy with that though. Firstly, configuring the Twitter client is quite awkward within the method. Let’s define a method that returns a fully authenticated client:

# app.rb
def twitter
  @twitter ||= Twitter::REST::Client.new do |config|
    config.consumer_key        = ENV["TWITTER_CONSUMER_KEY"]
    config.consumer_secret     = ENV["TWITTER_CONSUMER_SECRET"]
    config.access_token        = ENV["TWITTER_ACCESS_TOKEN"]
    config.access_token_secret = ENV["TWITTER_ACCESS_SECRET"]

Now we can just call

in our
action and be done.

# app.rb
post "/messages" do
  content_type "text/xml"

Securing the Endpoint

Alright, not quite done. There’s a problem here in; if anyone finds out your Twilio number they can send messages to it and start posting to Twitter on your behalf. Let’s make sure that we are only getting messages from your number:

# app.rb
post "/messages" do
  twitter.update(params["Body"]) if params["From"] == ENV["MY_PHONE_NUMBER"]
  content_type "text/xml"

The app now checks to make sure that the SMS is sent by your phone number, but what happens if someone tries to spoof that? We can actually protect the endpoint with the Rack middleware that comes with the Twilio Ruby gem. It just needs one more line of code, place this before the action:

# app.rb
use Rack::TwilioWebhookAuthentication, ENV["TWILIO_AUTH_TOKEN"], "/messages"

The application will now sign requests that come to the

endpoint with your Twilio auth token and compare it with the signature Twilio sends in the request headers. To read more on how Twilio signs requests, check out our security documentation.

Send that Tweet!

We nearly have everything in place to send a Tweet from an SMS. We need to start our server up. That is a case of running the following on the command line:

$ bundle exec thin start -R config.ru

You should see Thin start up the application on
. Now we need to expose this application to the real world so that Twilio can send webhooks to it. I like using ngrok for this and all the details on how to get set up with ngrok can be found in this guide on testing webhooks locally by my colleague Kevin.

Once you have ngrok installed, run:

$ ngrok 3000

Now that is running, open up your Twilio account and edit the number you bought. Get your ngrok URL, add /messages to the end and enter it as the Request URL for messaging.

Add your ngrok URL as the number's Messaging Request URL

Save that and grab your phone. Type up a witty message about Tweeting by SMS, press send and open up Twitter to see the results.

A tweet to show it all working.

We Haven’t Written Much Code Yet…

I know, right! How else did you think all this was going to fit into 62 lines? This is the end of part 2 though, we’ve seen how to set up the application, respond to webhooks and use the Twitter gem to send a Tweet in response to a webhook. We also secured that webhook so that our Tweeting is safe and only ever from a number we expect it to come from.

In the third part of this blog post series we’ll see things from the other side. We’ll be watching the Twitter API for notifications that we want to turn into SMS messages. You can read ahead to see how it’s done by checking out the code on GitHub.

In the meantime, sit back and enjoy how little code is needed to turn an SMS message into a Tweet.

How to Send a Tweet with SMS (Send and Receive Tweets Using SMS: Part 2)

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 17, 2015

Your backlog is a mile high, your roadmap a mile long and your available story points always feel like they are half as many as you need. Everyone above you thinks the product should have shipped yesterday. Everyone below you is begging for another two sprints to complete their work, warning of grave technical debt. The dance of a technical leader is on the razorblade shoved between short term speed and long term ambition – parting with even a single hacker for a single day represents steep opportunity cost.9810112314_1578198502_z

Many shops can only part with their developers for one conference a year. For your developers, I want that conference to be Signal in San Francisco next month, May 19th and 20th.

Here’s why.

Zero Noise and No Fluff – Only Real Technical Talks

As developers, Signal was the opportunity to craft the conference we would want to attend ourselves – I hope you find the same when you look at the stacked schedule of talks. We reached out to the best technical speakers we’ve seen in five years of developer outreach and invited them to the conversation.

14660800984_aa69c79146_zOn our Twilio themed “Learn” track we’ve got all the folks that build Twilio coming to share what they’ve learned building products old and new. I’m particularly stoked to hear from my colleagues Coleen Coolidge and Daniel Palacio talk security at Twilio and within your Twilio apps. I always learn something new about the complexities of international from Lisa Weitekamp on our Phone Numbers team – a must see for anyone with a global customer base. And Peter Shafton and Bob Hagemann who will be talking about how Twilio builds Twilio – lot of killer lessons of scale learned by these Twilio veterans. 

No pitches. Only real technical sessions for the working developer.

The Developers Building The Tools You Use Right Now

No one builds an app with Twilio alone. By liberating communications to be built into the applications you are already creating and the languages you already know, the software that connects your customers via voice, messaging or video is built on the same stuff as your product. 

This is why we loaded Signal up with two more tracks featuring pragmatic talks about the technologies we all use. The first track “Insight” contains practical talks about technologies, design patterns and concepts we see used frequently in Twilio applications. But not just the theory behind these ideas, but useful insight on their practical application.

Guillermo Rauch will not just be talking about socket.io, but how you can use it to supplement an existing web application. Leah Culver won’t just be talking about Swift, but best practices on using it to interact with a REST web service. Philipp Hancke won’t just be talking about WebRTC, but sharing wisdom learned the hard way on how to debug it in practice.

Signal is not just a Twilio conference – it is a conversation about all the technology that you use with Twilio every day.

Straight Talk From The People Who Built It

Our last track is definitely my favorite – “Equip” is filled with developers from the Twilio community talking about the technical issues they encountered building stuff they love. James Montenegro from Xamarin will show how to create compelling communication experiences in C# and deploy to both iOS and Android devices. Adam Varga and Elliot Gardiner from Datalot will share lessons of volume when running a large call center on node.js. Finally, Kristina Durivage and Alan Palazzolo will have one of the most impressive hardware live demos we’ve ever seen.

Building something you love is never easy and when you’re embarking on the journey to connect people over multiple devices, browsers and channels, the potholes in the roadmap are rarely evident from the start. Hearing the straight dope from people who have done it before holds invaluable wisdom your developers will not have to learn themselves the hard way.

First Crack at the Latest From Twilio 

Developers at Signal will get a headstart on a host of new products, including the recently announced Twilio Video. We’ve got plenty more surprises we can’t wait to share with you at Signal. In addition to sessions from the engineers and product managers who built these tasty new developer tools, your friendly neighborhood developer evangelism and education crews will be on hand to sit down with you 1:1 and show you how they work.

Chat with London devangel Marcos Placona about integrating Twilio with external calendaring systems. Rap with New York evangelist Ricky Robinett about using WebRTC to create a photobooth. Even teach your dog to send selfies with Chicago’s Greg Baugues.

Signal Is A Conversation

9810112314_1578198502_zWe had very high ambition when we set out to create Signal for you eleven months ago. But all the speakers, new surprises, kickin’ band and an honest-to-God carnival for coders is all really aimed at one thing: starting a conversation with your developers.

The atomic unit of communications is the conversation – that uniquely human discourse between two people. Many of the conversations that will decide how we communicate for the rest of our lives are going to happen 19-20 May in San Francisco at Fort Mason.

You can register now at signal.twilio.com before prices go up. Your entire staff is warmly welcome; if you call us at (844) 849-8157 and we’ll make sure to hook you up with a group rate.

I hope you can join us for it. It won’t be the same without the voices of you and your developers.

5 Reasons Your Developers Should Come To Signal

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

Using Twilio’s SIP Interfaces, you can take advantage of Twilio’s Voice API with numbers on another carrier. Let’s say you have a great relationship and a ton of numbers with your local provider, or you need new numbers in a country we don’t cover (yet). If you need a conferencing service, IVR or the ability to route calls to WebRTC you can add those capabilities to your existing numbers with SIP Interfaces.

In this post we’ll walk through how to get set up with a number from an external number provider. For this walkthrough we’ll use Toll Free Forwarding but there are many similar providers. Any provider who can deliver calls over SIP will work, and the process to connect them will be similar to the one described here.

To get this setup we need to configure the Twilio side and then the carrier side.

In order to send traffic to a Twilio SIP domain that traffic must be authenticated with an IP whitelist or a username and password. For this use case we’ll use an IP whitelist. You can get a full list of Toll Free Forwarding signaling IPs from here but they’re also copied below.

To create an IP whitelist go to here. Give it a friendly name that will help you remember the IP group and then add in the following IPs.


The next step is to create a Twilio SIP domain. To do that go here, pick a domain name, and then add the IP ACL you created to the domain and hit save.


This completes the Twilio portion of the setup and you’re ready to receive calls from Toll Free Forwarding.

The next step is to create an account with Toll Free Forwarding to send calls to Twilio. Once you’ve created an account you can go to this page to see the phone numbers that are available.

In this case we’re going choose a Malaysia, Kuala Lumpur local number, but any number you need will work.


Now that you’ve bought your number you can go to here to see the numbers on your account. Next hit the “New” button under call actions.


Once that menu pops up, select “Call Forwarding”. Once that page loads select “Create New Ring-To”. Take a breath, you’re nearly done.


Once that page loads, paste in your SIP domain. When you paste in that box is what will come through in Twilio as the “To” of your incoming call. I put andrew@ but you could also enter your Toll Free Forwarding number like 60389885294@tollfreeforwarding.sip.twilio.com so you know which of your numbers was called.


Once you save that configuration make sure your number is set up with the call action you created. From there you are ready to go. Place a call to your Toll Free Forwarding number and you should hear your Twilio welcome message. Looking at your Twilio log you would expect to see an entry in this log.


I hoped this helped you get started bringing your own numbers to Twilio. This is one of the many uses for Twilio SIP interfaces. If you have something that speaks SIP like a carrier, softphone, or PBX, Twilio SIP Interfaces allow you to send calls in and out of these elements. We see our customers use this to add conferencing services to their existing PBXes, add on WebRTC clients as new endpoints or add Twilio to their existing phone numbers. We can’t wait to see what you build.

Bring Your Own Numbers with Twilio SIP Interfaces

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 16, 2015

Last October Hacker News launched their official API and I’ve been trying to find an excuse to play with it ever since. The idea finally hit me last week: what if I built an application that notified me via SMS whenever someone posted a link to my domain on Hacker News? Hacker News is known to drive a ton of traffic and I probably want to be ready to spin up some extra servers if I end up making it on the front page. If you’ve also been waiting for an excuse to play with the Hacker News API you’re in luck because today I’m going to show you how to build this application using Node.js, Firebase and Twilio.

Our Tools

Sit by the Fire(base)

It’s time to get our project started. First we will create a new directory called ‘hn-sms-notifier’:

mkdir hn-sms-notifier
cd hn-sms-notifier

Now let’s initialize our project:

npm init

One last thing before we start writing code, we need to install the Firebase node module:

npm install firebase --save

Now that we have our foundation in place let’s create a new file called index.js and start writing our code:

var Firebase = require("firebase");
var newStoriesRef = new Firebase("https://hacker-news.firebaseio.com/v0/newstories/0");

newStoriesRef.on("value", function(snapshot) {

We’ve only written five lines of code but let’s take a second to unpack what’s going on so far. First, we import the firebase library so that we can interact with the Hacker News API. On the next line, we’re getting a Firebase reference for the first element in new stories. Let me walk through why. We can view an array of all the new stories on Hacker News on Firebase at this url:


For our scenario we only care about when a new story is added into the first position. Which is the value here:


On the third line, we’re listening for whenever the value changes on this reference. Confused? It’s ok, this threw me off at first too! I thought I would be listening for when a child is added but this data is structured as an array with five hundred elements. When a new story is added to Hacker News the value in each element is updated with a new key. By listening for changes in the first element we’ll always receive a notification when a new story is added.

With that out of the way, it’s time to run our code:

node index.js

If you watch, you’ll see that every time a new story is added we log the ID of that story. At first you’ll only see one ID output at first but just give it time. Depending on the time of day it can take a few minutes for a new story to be added.

Story Time

You’ve probably realized that we need more than just the ID of the story. With the Hacker News API each story is an item and we can access information about that item from a URL structured like this: https://hacker-news.firebaseio.com/v0/item/%storyID%

Let’s add the code within our newStories value callback that gets information about our specific story:

newStoriesRef.on("value", function(snapshot) {
  var storyRef = new Firebase("https://hacker-news.firebaseio.com/v0/item/"+snapshot.val());

  storyRef.on('value', function(storySnapshot) {

Run your app again and you’ll see that we’re now logging information about each new story that gets added:

But the wise among you may notice we’re getting notifications each time the data in a story changes. That’s because we’ve subscribed to updates for that item in perpetuity. Set that issue asIDe, we’ll be fixing it a bit later on in the code.

You’ll see we have data like the title of the story, who posted the story and url. If we wanted to know whenever the user named sama posted a story, we could look at the by field or if we wanted to get notified whenever someone posts a story at WebRTC we could search in the title. But for our app, we’re going to use the url value so we can see if the story came from our domain.

Since we’re working with URLs let’s use node’s URL parser to make things a bit easier. We can start by requiring it at the top of our index.js file:

var Firebase = require("firebase");
var url = require("url");

var newStoriesRef = new Firebase("https://hacker-news.firebaseio.com/v0/newstories/0");

Now within the callback for our storyRef we can use url.parse() to get the host domain of each story:

storyRef.on('value', function(storySnapshot) {
  var story = storySnapshot.val();
  var host = url.parse(story.url).host;


Let’s run our app again and see it in action:


Ok, if you let the app run for more than a couple minutes it probably crashed. Don’t worry, we can fix this. What’s happening is sometimes Firebase fires the callback indicating a new story has been added before the story data is actually available. There are lots of ways we could fix this today we’re going to make sure our snapshot.val() isn’t null. If we don’t, we’ll just return. The great thing about firebase is since we’re subscribed to updates for this item the callback will get triggered again with the story data is added:

if(storySnapshot.val() === null) {

var story = storySnapshot.val();
var host = url.parse(story.url).host;

Remember that issue we had with getting multiple updates for the same story? We can fix that now too. Let’s unsubscribe from updates about our story once we know that we’ve retrieved the data about that specific item:

var story = storySnapshot.val();
var host = url.parse(story.url).host;

Run your app again and you’ll see we fixed both of our bugs. Isn’t fixing bugs fun!?!

Alert! Alert! Alert!

Our app is pulling new stories from Hacker New and getting the host that the story links to.  The last thing we need to do is check to see if it links to our host and notifies us via SMS if it is. For sake of being able to quickly test our app let’s check for a domain that we know gets frequently posted to Hacker News: “github.com”:


if(host === "github.com") {

Before we can send our text message we need to install the Twilio node library:

npm install twilio --save

We need to require our Twilio library at the top of our file:

var Firebase = require("firebase");
var client = require('twilio')('ACCOUNT_SID', 'AUTH_TOKEN');
var url = require("url");

Make sure to replace the ACCOUNT_SID and AUTH_TOKEN with your own Twilio credentials. You can find these in your account dashboard.

Within our conditional that checks for our host let’s add the code to send our SMS message. Replace the to and from phone numbers with your phone number and twilio number:

if(host === "github.com") {
    body: story.by + " just posted " + story.title + "on HN!",
    to: "+15555555555", // your cell number
    from: "+15555551234" // your twilio number
  }, function(err, message) {

It’s the moment of truth – start up your app up again and wait… you’ll get an SMS message when someone posts a story linking to ‘github.com’ on Hacker News. Once you know it works replace github.com with your own domain, fire up the app and wait for it to work it’s magic.

I’m Not Just Reading Hacker News, I’m Working!

We can now get SMS notifications when someone posts a story to our domain on Hacker News. But most importantly, we’ve learned how to work with the Hacker News API and can safely tell our bosses that we spent all afternoon looking at Hacker News for work. Have questions or want to share what you’re going to build with the Hacker News API? Holler at me on twitter (@rickyrobinett) or e-mail (ricky@twilio.com)

Get Notified When Someone Posts An Article From Your Domain on Hacker News Using Node.js, Firebase and Twilio

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 15, 2015

I’ll give you a starting point and an end point and leave you to fill in the middle.

Kenneth Reitz’s dad is a programmer. At a young age, Kenneth’s dad helped him learn Turbo, C++, and Pascal. Unsurprisingly, Kenneth is now a programmer, or more accurately, Python Overlord at Heroku.

You might assume the road to Python Overlord was paved in gold, given Kenneth’s slam dunk combo of having passion for coding and a technically savvy dad. You’d be wrong. Kenneth found his niche in Python coding after trudging through a few bad jobs, dropping out of college, and above all — following his gut.

Kenneth has an apt explanation for dropping out of college. It was a lazy river. He knows plenty of terrible programmers who have CS degrees. He also learned that his time is better spent chasing things that inspire him, than chasing a diploma. While the unfettered access to computers was “like a playground” to Kenneth, the rigid classroom style learning left him deflated and uninspired. Without that spark, Kenneth couldn’t be productive.

[Catch Kenneth’s talk “API Driven Development” at Signal, May 19th-20th in San Francisco. Register here]

“If I happen to be inspired towards something in a moment, if I take the opportunity to work on that thing in that moment, I will be a thousand times more productive in that moment than otherwise. So, I try to pursue those moments.”

Chasing that inspiration led Kenneth outside of the classroom and into his first job at a .NET shop. He quickly started coding in Java, PHP and Python. Once he got into Python, it was game, set, match. Kenneth found a language whose possibilities inspired him. He dove into Python full bore and eventually got the spot as Python Overlord at Heroku.

“What’s really inspired me as someone who is creative is really great software. I’m always looking for the best way to do X,” Kenneth says. That pursuit keeps Kenneth building, and keeps him on the hunt for creative builders who might show him a new API or a new bit of software.

He’s not quite sure what he’ll stumble upon that will peak his interest. He’s just knows it’s coming and delights in the fact that it will surprise him. “There’s cornucopia of great software out there,” he says, “I know it’s going to be completely different than I expect an that’s the exciting part.”

Kenneth Reitz: Ditching The Diploma, Pursuing Inspiration In Programming

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

The Apple Watch will not be available for more than a week yet, but already TigerText has released an app that lets users send and receive messages to the device. TigerText today launched TigerText for the Apple Watch, which lets users  send and receive messages hands-free. Apple Watch owners will be able preview, read, and send secure messages in real time, as […]

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 14, 2015

Today, we announced Video. Developers can now create fundamentally better experiences by embedding live peer-to-peer video into mobile and web applications. Video is much more than just being able to talk face to face. Video enables users to share what it is they’re working on, and to express things that cannot be expressed with voice and text alone.

Attendees at Signal will be the first to get their hands on the beta (May 19 & 20 in San Francisco). In the meantime, you can get on the waitlist for early access on www.twilio.com/video and learn more at our meetups in New York (Apr 20), San Francisco (Apr 21) and Mountain View (Apr 22).

Using video to create better experiences

Before we jump into the details, here’s an example of why we’re excited about this. ZenDesk was one of our first customers to take Twilio Video for a test drive. The Twilio crew flew out to Zendesk’s office in Dublin, Ireland to build the proof-of-concept. The idea was simple: What if we could take advantage of the camera on a mobile phone to completely change the mobile customer service experience? ZenDesk already enables customer support teams to answer customer service phone calls directly in the ZenDesk browser app. They also enable businesses to embed Zendesk’s customer support features directly into customer-facing mobile apps through their Embeddables SDK. We wanted to combined Embeddables, Zendesk’s agent interface, and Twilio Video to help customer service reps see and solve problems first-hand.

The combined team had a prototype integrated into ZenDesk working within a day, and a polished demo within a week. In the final demo app, customers can tap a button to connect with an agent over video, and share the front or rear cameras from their mobile, or the screen of their mobile device. Agents can capture video frames and add them directly into a Zendesk support ticket when they see something of interest. The outcome is a richer customer support conversation, one where a customer can show a support rep the specifics of the problem they are grappling with, rather than trying to explain it in words.

Twilio Video is a combination of cloud infrastructure and client-side SDKs. The Cloud Infrastructure provides all of the orchestration for setting up a video call: Registration, signaling, and media routing. The new Twilio web and mobile SDKs provide the other half, making it really easy to consume these services across the different supported platforms of iOS, Android and JavaScript.

Built on WebRTC

When we set out to build Video, we knew we wanted to one day reach every device and every platform with realtime communications capabilities. This is why WebRTC, the open standard for realtime communications, sits at the core of Twilio Video. WebRTC already has strong support in the Chrome and Firefox web browsers, allowing users to leverage video capabilities without installing software or plugins. The open source WebRTC libraries are designed for cross-platform compatibility, opening up a world of mobile, desktop and IoT devices to the standard.

But WebRTC is just a piece of the puzzle, not a solution. To take advantage of the standard, you still need to provide registration, signaling, and network traversal to enable endpoints to find one another and establish connections. Twilio Video makes this happen with its Video orchestration services available in 28 data centers in 7 geographies around the world.

The cloud isn’t the only place where some heavy lifting is required. WebRTC, in its native form, is optimized to work well in a web browser running on a powerful desktop device. Twilio’s SDK team is investing massive energy to make sure the platform performs well in more constrained computing platforms, such as iOS and Android devices, and on a variety of hardware configurations. Optimizing media quality and SDK performance is an ongoing mission–we’re always testing and tweaking to squeeze the best performance out of the platform.

Designed for a new breed of applications

We know that the next generation of communications applications will change the way we connect, work together and share with one another, and get things done. We know this new world needs a new breed of communications primitives.

That’s why Twilio Video has been designed from the start to support multi-party voice and video calls. Up to 4-way peer-to-peer calling with Twilio Video gives you the ability to add participants ad-hoc to a voice and/or video conversation. To enable that, Twilio Video provides:

  • Unlimited video connections: Registration and Signaling capabilities are globally distributed and designed to scale elastically as load increases.
  • Low latency relay: Automated network traversal enables peer-to-peer connections across firewalls. The closest Twilio data center is automatically chosen as the media relay point when firewall conditions prevent a peer-to-peer connection.
  • Optimized Mobile Media Stack: Optimized for iOS and Android, Twilio SDKs ensure great quality real-time media on mobile devices despite common network challenges such as jitter, packet loss and latency
  • Cross Platform Data Channel: All peer to peer calls have access to a DataChannel between users, allowing data transfer directly over DTLS/SCTP alongside the media flows. This can be used to send files, send arbitrary JSON data or anything else. For example, a user can draw on top of the video they’re viewing, and the data for that can be transferred and shown immediately on the other side.

We’re really excited about Twilio Video. Whether you’re building a face to face communication service, or building video into your existing app to create great customer experiences, we can’t wait to see what you build.

Announcing Video

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

April 13, 2015

dog-on-the-internet-by-peter-steinerThe way Eric Ries got his first break in programming is a classic story of supply and demand, with a few sizable white lies tossed in there.

Eric can explain feeding a major publishing house some not-so-true tid bits of information as a teenager with surprising brevity. “You know that famous New Yorker Cartoon?” (Take a look to the right) “Well, On the internet no one knows you’re a kid.”

The publishing house that printed Eric’s first coding tutorial had no idea he wasn’t a veteran coder, java expert, or an adult. He was a cocky teenager, convinced he could publish a tutorial on Java programming despite the fact that he learned Java two days before pitching the publishing house. The best part is, Eric was right.

[Catch Eric Ries’ keynote at Signal, May 19th – 20th in San Francisco]

“Not only did I think I knew programming in high school, I thought that I could teach programming,” says Eric. “I was an arrogant kid.” The key to Eric’s success with the publisher was that his arrogance was matched by his ingenuity. His code was on par with the adult, 40-something engineers he was pretending to be. He never talked to the publisher on the phone, for fear his voice would give away his age. It all went well, until he had to write his date of birth on the publishing contract. That’s when he got a call from the publisher that he couldn’t ignore. The publisher wanted Eric’s parents to endorse the deal. That was it. A few months later Eric, a 17 year old, was a published author. Heck, he was an expert in print. The one chapter in The Black Art of Java Game Programming served as one small step for Eric into a career of programming.

Looking back, Eric fully recognizes how ridiculous the story sounds. But people do crazy things for love, and Eric was deeply in love with programming. He just didn’t know that he could do the thing he loved for a living. “Nobody told me you could make money as a programmer. It didn’t even occur to me. A year after high school I realized you could do programming for a living, and get a job, and that was one of the happiest days of my life. I couldn’t believe it. It was like someone was saying you could play video games all day.”

If programming was like playing video games, Eric wondered if he really needed someone to teach him how to play video games. It turns out that the folks at Yale have a good track record for the whole teaching people thing, so Eric went to Yale. He founded a recruiting site, sold it, and made some pre-DotCom-bubble burst money and quickly looked to his next venture. He can’t remember when he caught the entrepreneurship bug, it was just there in him. He learned that while you can teach someone to play video games, you can’t teach them to love video games. Eric loved video games.

The same teenage love that made Eric do crazy things for programming, fuels his career as an entrepreneur. Eric believes that you have to have an unquestioning passion for what you build. There are an impossible number of pitfalls you will undoubtedly cross on the way to successfully founding, running, and growing your business. If you don’t have what Eric calls a “vision” for your business, and the passion to back it up, there’s little point in trying.

“Starting a company is so hard, there’s no point in doing it if you’re not passionate about it. There are so many other ways to make money if you just want to make money. You have to have a vision for the world to be a better place because of what you’re doing.” “When things are going wrong, you can give up. But when you have a vision, you can see it so clearly that it has to come true. You say ‘something’s going wrong, how do I change my strategy and figure out what I need to learn to make my vision successful.’”

In this light, you can see Eric’s little white lies to the book publisher as a teenager as his very first pivots. They were his very first steps on the road to being an entrepreneur.

Eric Ries: On The Internet, No One Knows You’re A Dog

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

Image of learn button on keyboardParents and educators that work with struggling readers are faced with many challenges such as helping the student stay at grade level and motivated, dealing with feelings of isolation and even bullying. However there is a growing amount of resources to help those dealing with learners with disabilities.

Here are just a few sources for the families of struggling readers that we think are worth a look:

Reading Rockets’ section on learning disabilities. The Reading Rockets project is guided by an advisory panel made up of leading researchers and experts in the field of reading and includes PBS television programs, online services, professional development opportunities, and a social community.

Reading Rocket’s sister site LD OnLine, is a leading website on learning disabilities for parents and educators.

Understood.org is also an excellent non-profit resource for learning and attention issues. We recommend accessing the myriad of articles they have discussing subjects such as what every parent needs to know about reading and text to speech, what it is and how it works.

It is also important seek out inspiration, and the Internet is a perfect place to do so. Students as well as parents will be encouraged when they see that they are not alone with their learning issues. Take this video about Ben, a determined boy with dyslexia and a wonderful story. His use of audio to read the Harry Potter series just goes to show how powerful bimodal learning can be for struggling readers.

Whether looking for resources, information or support, parents are encouraged to research on-line and reach out to the organizations that seem to be the best fit for both a child’s issues and the family’s own philosophy.

Image Credit: Jake Rust

Bookmark this post:
Ma.gnolia DiggIt! Del.icio.us Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google

Last updated: April 26, 2015 04:01 AM All times are UTC.
Powered by: Planet

Speech Connection and Logos are Trademark of Nu Echo Inc. Copyright 2006-2008.