tjlytle

At Nexmo we've been powering similar solutions for a lot of apps through our SMS API. However, we've just released a higher-level API that leverages our SMS / Voice APIs to make this kind of number verification easy to implement. Ours includes multiple deliveries and channels (falls back to a voice call if needed). We're looking for early adopters, would love to have you take a look: https://docs.nexmo.com/index.php/verify

What provider are you using for sending the SMS?

I'm sure the team would appreciate the feedback as to where the deliverability was less than another provider. Also, might want to ask about the recently added tools to use your conversion stats to help route traffic.

Nexmo also provides deliverability statistics: https://dashboard.nexmo.com/ratios/public

Disclaimer: I do a bit of part time dev evang for Nexmo.

Nexmo should be pretty good across the board as it pertains to what delivers best (direct to carrier model: http://blog.nexmo.com/post/4690069179/directsms). In that way, Nexmo is trying to solve the issue you're having.

Have you had any issues with deliverability and Nexmo (where another provider delivered better)? Nexmo actually provides some tools to automatically optimize traffic based on client conversion ratios.

Would be interested in knowing how you're doing the content filtering. Returning a filtering proxy server in place of the actual server?

Composer as well (http://getcomposer.org/) - no one true way with PHP, but that doesn't mean there can't be a few good ways.

True. Not a strength for the language though - if that's a big part of what you do, then I'd consider something else. That said, I've built plenty of applications that used PHP on the command line or as a daemon.

There are pros/cons to any language. If you're developing something web related, PHP is certainly worth considering (especially in your case, as you have experience with it).

Just a few quick thoughts:

PHP is - in most cases - very tightly coupled to the HTTP request. This can be good or bad depending on what you're building. Doing a lot of offline processing? Probably bad. Serving up web pages? Probably good.

There's no (or little) state with PHP (you do have the session, which can be pushed to memcache), so - generally speaking - running your application across a bunch of web nodes isn't too hard to implement (even scaling the horrible legacy style code that helps give PHP a bad reputation shouldn't be too hard). This may or may not be important to you.

There's really no one true way with PHP - it can be used for a simple 10 line script, or for a large scale web application. If you like (or need) that kind of flexibility, it could be a good choice.

Bottom line is - it's certainly sill worth considering, just know why you picked it (or whatever other language/platform you use).

That said "it's what I know" or "I wanted to try something new" aren't necessarily bad reasons.

Right now I'm a contract developer (building web applications for clients) - if that wasn't possible (and, since it seems like a cop out, I'll ignore non-internet related programming) I'd likely be a carpenter/tinkerer (building physical things for clients).

CloudMine (https://cloudmine.me) recently updated their dashboard, and while I haven't had a chance to really work through it all, it looks pretty nice.s

Since it's backend as a service, allowing access to view/edit/troubleshoot the data is key.

Also, CloudMailin's (http://www.cloudmailin.com/) 'Try it Live!' is a pretty nice demo of the API.

It's an easy read - not something you can always say about technical books.

I thought it did a good job filling the gap between 'how to write automated tests' and actually writing tests for real world code.