How patio11 builds Twilio apps(twilio.com)
twilio.com
How patio11 builds Twilio apps
https://www.twilio.com/blog/2015/01/how-patrick-mckenzie-builds-twilio-apps.html
11 comments
OP here. I'm so sorry to hear that we let you down like that. Totally not what we're striving for. Wouldn't be surprised if you've moved on after an experience like that, but if you need any help from us in the future and you're not getting what you need, please feel free to reach out to me directly ([email protected]).
Thank you, and I appreciate it. If I get abandoned again in the future, you'll be the first person I contact.
There are at least two possible explanations:
1) Customer service response is highly variable
2) Twilio (like any company) is extra-responsive to customers who have a large audience on the Internet
1) Customer service response is highly variable
2) Twilio (like any company) is extra-responsive to customers who have a large audience on the Internet
Of course, and I completely agree. I'm just trying to provide a contrasting opinion from a normal user who doesn't have a huge internet audience.
Twilio is useful, and not too expensive. It's most useful for SMS input, since it doesn't understand voice; it just records it. I just use it for a fun application; I have it connected to a 1930s Teletype machine at steampunk conventions, so people can send in telegrams to be hand-delivered.
Inbound SMS is still limited to 160 characters; Twilio can't reassemble a multipart SMS message, or give the user enough info to do so. Nexmo, a competitor, can handle multipart inbound SMS. I wish Twilio would catch up in that area.
Inbound SMS is still limited to 160 characters; Twilio can't reassemble a multipart SMS message, or give the user enough info to do so. Nexmo, a competitor, can handle multipart inbound SMS. I wish Twilio would catch up in that area.
I'm pretty sure we successfully do long messages on twilio now- thought they solved this issue back in 2014 Q1?
No, not solved. Twilio can now send long SMS messages, but still cannot receive them properly.
Now that everybody has smartphones, which do SMS split and reassembly invisibly to the user, the 160 character limitation is more of a historic thing and users are not aware of it. In practice, most long SMS messages are outbound, because they're marketing messages or spam, so this isn't a problem for most Twilio users.
Technical details, for anyone interested:
Multipart SMS messages have a binary header which carries the sequence number info necessary for reassembly. The Twilio API for incoming SMS (https://www.twilio.com/docs/api/twiml/sms/twilio_request) does not pass that through. The user's application gets multiple message parts from Twilio ("For incoming messages that are greater than 160 characters, the sending carrier will break up the message behind the scenes before delivering them to us, so Twilio will treat them as separate incoming messages and deliver them to your application in the order we receive them.") but without the info needed to put them back together properly. So the customer's program processes the first part right, and is then confused by the disconnected chunks of text in the later parts.
The Nexmo API (https://docs.nexmo.com/index.php/sms-api/handle-inbound-mess...) does: see the fields under "Specific Parameters for long 'concatenated' Inbound". The parts may come in any order, but they have ID numbers and "part N of M" info, so the user can reassemble them. Twilio support once talked about doing reassembly on their end, but that was never implemented.
Here's Twilio support and a Salesforce user talking about this on Stack Overflow: http://stackoverflow.com/questions/21025795/combining-a-mult...
Technical details, for anyone interested:
Multipart SMS messages have a binary header which carries the sequence number info necessary for reassembly. The Twilio API for incoming SMS (https://www.twilio.com/docs/api/twiml/sms/twilio_request) does not pass that through. The user's application gets multiple message parts from Twilio ("For incoming messages that are greater than 160 characters, the sending carrier will break up the message behind the scenes before delivering them to us, so Twilio will treat them as separate incoming messages and deliver them to your application in the order we receive them.") but without the info needed to put them back together properly. So the customer's program processes the first part right, and is then confused by the disconnected chunks of text in the later parts.
The Nexmo API (https://docs.nexmo.com/index.php/sms-api/handle-inbound-mess...) does: see the fields under "Specific Parameters for long 'concatenated' Inbound". The parts may come in any order, but they have ID numbers and "part N of M" info, so the user can reassemble them. Twilio support once talked about doing reassembly on their end, but that was never implemented.
Here's Twilio support and a Salesforce user talking about this on Stack Overflow: http://stackoverflow.com/questions/21025795/combining-a-mult...
I didn't know teletype machines were that old. By any chance, do you happen to have a video available?
https://vimeo.com/97062822 -
https://archive.org/details/Aethericnovaalbiion2011
https://archive.org/details/Aethericmachine14
http://www.aetherltd.com/refurbishing.html
Those are some of my machines. Those machines were built between 1924 and 1944. There are older printing telegraph machines, back all the way to 1852, but the Model 14 from 1924 was the first one that "just worked". So hundreds of thousands were produced, and many are still around. If you want an old Teletype, there are usually some on eBay.
https://archive.org/details/Aethericnovaalbiion2011
https://archive.org/details/Aethericmachine14
http://www.aetherltd.com/refurbishing.html
Those are some of my machines. Those machines were built between 1924 and 1944. There are older printing telegraph machines, back all the way to 1852, but the Model 14 from 1924 was the first one that "just worked". So hundreds of thousands were produced, and many are still around. If you want an old Teletype, there are usually some on eBay.
Thanks for such a thorough reply. I'm sorry I just saw it now, 9 days later. Thanks again.
Many technologies are older than people think. Fax machines, for example, have been in use by the US military since the Civil War.
Great piece. More B2B companies should offer customers promotion in exchange for stories of how useful their product is. Major win-win. And of course 'patio11 is doing odd and clever things with twilio aside from his business. :)
Minor nitpick: Incorrectly states he's the highest karma user of HN, when 'tptacek has almost double his karma, and pg is #2 even though he's not on the list of high-karma users.
Minor nitpick: Incorrectly states he's the highest karma user of HN, when 'tptacek has almost double his karma, and pg is #2 even though he's not on the list of high-karma users.
Haha. I knew someone was going to call me out on that -- tried to phrase his HN status succinctly and came up ambiguous. I was looking at the average rating on the top 10 list, but you're absolutely right that a couple folks have more gross karma. Semantics matter. Thanks for pointing that out.
And thank you too for the compliments.
And thank you too for the compliments.
I loved the in depth discussion of his process for making the app more stable. Is there any other good articles or books about making applications more stable and reliable against hard failure?
>Someone could be logging in to their dashboard and the web service basically is like, “Well sure, I’ll serve up your dashboard HTML at the moment, but I got to send these phone calls out right now so you’re going to wait.”
Why not just use a push queue like iron.io so that it doesn't block http at all?
Why not just use a push queue like iron.io so that it doesn't block http at all?
More moving parts, more points of failure, async queues make problems much harder to debug (you no longer have a "stack trace" that tells you where your bad data came from, you just know it came off the queue like that). Async queues have advantages for many problems but they don't come for free.
Sure, but those are in most cases easily surmountable, and the advantages in this case sound somewhat higher than the downsides. Who knows...except @patio11.
Waiting for patio11 to show up here :)
Reliability, FSM's... Erlang might be a good fit for people working with Twilio - I wonder if there's any kind of API though.
Sounds like fun though - there's something cool about doing stuff in the "real world" beyond the screen that is somehow satisfying.
Sounds like fun though - there's something cool about doing stuff in the "real world" beyond the screen that is somehow satisfying.
Here [0] are a list of Twilio libraries. I used the erlang one a couple years ago for a pretty basic application, similar to patio11's. I was traveling to Canada for a couple weeks and picked up a pre-paid SIM. I set up my primary phone to forward to my twilio number which in turn connected to my temporary number. Pretty unnecessary (I received no calls, and often forgot my phone at the house I was staying it), but a good learning exercise.
The erlang library is at [1]. It doesn't look like it's been touched in a while, though. I've also not touched Twilio since then so I have no clue if that's an issue or not. Though I'll probably use a similar setup for a longer trip planned for this summer so maybe I should track down that code.
[0] http://www.twilio.com/docs/libraries
[1] https://github.com/huffman/twilio_erlang
The erlang library is at [1]. It doesn't look like it's been touched in a while, though. I've also not touched Twilio since then so I have no clue if that's an issue or not. Though I'll probably use a similar setup for a longer trip planned for this summer so maybe I should track down that code.
[0] http://www.twilio.com/docs/libraries
[1] https://github.com/huffman/twilio_erlang
We use both nexmo and twilio, and I prefer the nexmo. Better coverage, features etc.
Whats the best way to insert <Say> in a <Play>, splitting the mp3 up?
You'd have to split the mp3 on your end. then it's simple just:
<Say>message</Say>
<Play>part1.mp3</Play>
<Say>message</Say>
<Play>part2.mp3</Play>
...
etc...
But I could be missing the point of your question?
<Say>message</Say>
<Play>part1.mp3</Play>
<Say>message</Say>
<Play>part2.mp3</Play>
...
etc...
But I could be missing the point of your question?
That's what I feared. Didn't know if there was a way to do like a delayed <Say> into a <Play>
twilio is great but the toll free number is seriously expensive. the android client is a joke and you can't use it to answer or make calls. what twilio needs is an official skype like app.
Twilio is built for integrations, not end users.
Very nicely written article, a good PR piece! I'm just curious about how much patio11 was paid by Twilio for that.
A potbelly sandwich and a bag of chips. I get rather substantially more monetary consideration from Chase Bank as a consequence of my relationship with Twilio than I do from Twilio. (I spend +/- $7k per year on Twilio, so 1% CC rewards is $70 cash money. Chase clearly has me on the take!)
Seriously, though: I've never taken money for promotion from anybody. That's not my business model, which is straightforward: mostly, I sell software to businesses for money. It's not terribly difficult to get me to write or speak for free, since I love writing and speaking about geeky subjects, as evidenced by about 2 million words on my blog or HN comments.
Seriously, though: I've never taken money for promotion from anybody. That's not my business model, which is straightforward: mostly, I sell software to businesses for money. It's not terribly difficult to get me to write or speak for free, since I love writing and speaking about geeky subjects, as evidenced by about 2 million words on my blog or HN comments.
Thank you for answering, I was genuinely curious, this feels like you put a lot of work in it.
Based on my much less intense use of Twilio, they wouldn't have to pay me a cent to get me to write a glowing article like this. They're really good, their documentation is very useful and crystal clear, all I needed to get my code working, and their system just plain works.
(Again, in my much more limited use of it.)
(Again, in my much more limited use of it.)
I have to disagree with this. I've had a number of problems with both Twilio's customer support (failing to simply explain how to do something when I stated what I was trying to do) and also with their technical support (completely abandoning me for a week despite me immediately following up with what they'd requested and then asking for status updates).