Remember folks, for apps that use the back-end as a JSON service, nearly all the code is running on the client. If you have no feedback about errors, you are assuming your 15 minutes of testing with Safari on a Macbook is representative of the entire Internet including that guy with IE7 on XP with the Bing Toolbar. It's not a good bet.
They mention tinyfeedback but there is also DamnIT and the YC-funded proxino.
Learn me to trust my own fucking logs, will you.
One of the more useful monitoring tools I've got is a simple shell-wrapped "HEAD" script that polls our cluster and reports an "OK" or "ERR" (slow responses trigger a "Hrm..", along with the current, median, and standard deviation of the response, and total error counts. That sits in an omnipresent, always-on-top small-font terminal window.
Something like:
2012-03-30 12:03 i=9948
Host Status Cur Med sd Err
www OK 0.22 0.24 0.44 6Seems like it would be a really useful contribution to the JS development community to make this available for everyone to use.
> We constantly have to ask ourselves: are we causing any issues or slowdowns on our customers’ websites? [sic]
The GP's noting of irony (is that correct?) seems to be valid.
The seem to be backing up their site or something.
Like the name or not, it is why we came up with the Web 2.0 moniker. Sending "raw" data over HTTP to a richer client is quite a bit different paradigm to what was envisioned for the web.