> I'm generally pretty happy with Twilio's responsiveness to everything over the last couple years.
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).
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 (gb@twilio.com).
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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).