tjlytle

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.

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

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).

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.