Brian Marick

I am reminded of this Brian Marick classic: http://www.exampler.com/testing-com/writings/automate.pdf

The real "problems" with TDD are (a) in the "driven" part, not the "test" part. Tests are (in general) a good thing. However, using a series of tests to drive your design (aka "TDD is not a testing method,it is a design method" idea) often gives you an illusion of progress as you hill climb using conformance to an increasing number of tests as a progress heuristic and end up on top of a local maximum (as for example in the TDD sudoku episode). (b)in conflating TDD with one or more of (1) testing, (2) automated testing (3) automated regression test suites (4) developers adding more tests to the automated regression test suite as they develop more features, refactor, debug etc. You can have (1) to (4) without either (5)writing tests first (aka "don't write a line of code without having written a test covering it") or (6)driving your design with tests. The last two ideas are the real distinguishing features of TDD and are of debatable merit. None of (1) through (4) are novel ideas. (5) and (6) are where differences of opinion happen. Even if you choose to use TDD, it is good to be aware it is just one tool in your toolbox and not necessarily the default tool to reach for. (c) in the zealotry of some of its evangelists who insist that TDD is some kind of moral imperative and is the only "correct" way of developing software and anyone who doesn't follow that path or make respectful obeisance to it is "unprofessional","dodgy" etc. This is often accompanied by conflating…

Here's some examples I found pretty quickly: https://www.ibm.com/developerworks/aix/library/au-buffer/index.html http://www.exampler.com/writing/ring-buffer.pdf A google search for "logging to a ring buffer" will provide more.

This might work at low traffic levels, but there are better ways. In our internal error catcher, we've seen deploys that caused 20,000+ errors in under a minute. Even when we used similar techniques to mail ourselves errors on a low traffic site, it was important to introduce dead time, not alerting again for (say) 5 mins after the first alert so as not to flood our inbox. A useful technique btw is to use a ring buffer to collect debug logging, and when an error occurs dump this buffer into the message along with the stacktrace. It gives you more context when you're not logging debug to disk, and is fast. (see eg http://www.exampler.com/writing/ring-buffer.pdf, https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/SMTP… Services like https://www.pagerduty.com/ can contact you on more channels when problems happen, and also deal with dead time etc not /re/ alerting you constantly. The Slack mobile client would have got every one of those messages as a push. Pagerduty won't help with aggregating/exploring stacktraces though, for that, there's eg https://airbrake.io or for mobile apps, https://try.crashlytics.com/. Finally there's also http://www.splunk.com/ for aggregating logs; you can build some quite complex queries from it and do alerting on the results (not quite as fancy as pagerduty, but functional). There are many other tools in this space, worth looking around to see if there's any SaaS you can use or crib ideas from.

> There just isn't anything on the web that compares. (or if there is, please please tell me!) The breadth and depth of well-written technical information available on the web is far, far beyond what was available in Byte in its heyday. Consider: http://lwn.net/Articles/428530/bigpage http://www.airs.com/blog/archives/category/programming http://hackermonthly.com/issue-10.html http://blogs.msdn.com/b/oldnewthing/ http://prog21.dadgum.com/ http://www.dadhacker.com/blog/ http://diveintomark.org/ http://lambda-the-ultimate.org/ http://www.facebook.com/Engineering http://research.google.com/video.html http://rentzsch.tumblr.com/ http://perspectives.mvdirona.com/ http://www.exampler.com/blog/ The big difficulty these days is not getting access to well-written, broad-ranging tech material; it's choosing which well-written, broad-ranging tech material you want to read out of all the immense quantity of material out there, and avoiding spending all of your time reading it. Services like HN, Reddit, Digg, Facebook, Delicious, and Slashdot basically exist to solve this filtering problem (although not, obviously, limited to the tech press). > What gets funded on the web isn't determined by what users want - it's what advertisers will pay for. That's true, but fortunately it's irrelevant, because what gets written about on the web isn't determined by what gets funded—it's what people want to write about.