DeCare Systems Ireland Blog

I had intended to start today with a brisk, rousing discussion on threads, but had to settle for the “Future of Unit Testing”, as the talk was cancelled. I usually prefer very technical talks, in fact the more impenetrable the better. The talk actually turned out to be interesting though and not as fluffy as it might have appeared at first glance. It was given by TypeMock’s, Roy Osherove. TypeMock currently make the best .NET Isolation Framework in my humble opinion, pity it’s a commercial product. It’s hard to justify purchasing software when so many effective, free alternatives are available.

Roy prefers to avoid the “Mock” word with regard to faking, as he described it, unit test dependencies. The “Mock” term does often get confused with “Stub” in describing test related artefacts. He also coined the concept of an “Isolation Framework” instead of a Mocking Framework. I think that’s a much neater fit. Many of the current Unit Testing related offerings were discussed for relative merits and observed trends, and a pretty shrewd prognostication on automated testing as a whole was forthcoming as well. My favourite methodology IOC got a strong mention, but surprisingly Spring.Net didn’t.

The next discussion was a description of a methodology developed to cost effectively scale an extremely large user base web site. Novel concepts and counter intuitive assertions were made and dissected. The basic elevator premise turned out to be:

Make as much data as static as possible, and then house it in commercially available content delivery networks, thus delegating traffic away from your key infrastructure.

Where data absolutely can’t be made static, cache it in a distributed fashion, by making cache updates occur via a pub/sub model, without any synchronisation at all.

That’s it in a nutshell. The whole thing was delivered in a super clean implementation with some ridiculously high performance figures casually tossed about. Ah, but what about the lag between submitting a data change and receiving the cache update by subscription you roar! Well turns that in 99.999% of situations, the lag be compensated for, particularly when the client realises the overall delivery scales for about 5% the cost of an equivalent, truly real-time system along conventional lines. While the story was fascinating, I can’t help feeling that maybe the client wouldn’t have been so bold as to adopt this technique, if their catastrophic performance issues hadn’t been such a proverbial gun to their head.

After lunch, in the strangely labelled graveyard session, I attended a companion talk to yesterday’s Concurrency Runtime discussion. This seminar focused on managed code implementations of the new Task and Parallel APIs. I must confess I’d seen them in action before, but wow. Every time I see this stuff I want to use it. Unfortunately, I have to wait serenely for version 4 of the .NET API to be released before it will escape imprisonment from within CTP. Maybe I’ll get the chance to early-adopt the hell out of it on one of DSI’s projects.

The next session was an Interactive session with the same SQL Server Technical Architect that delivered yesterday’s SQL Tricks session. Unfortunately his voice crashed sometime directly after yesterday’s session. So, about 75% of today’s talk was delivered in a whisper. But what a whisper! This stuff related to T-SQL index usage and boy was it gold.

If you ever ask a DBA for a hard and fast rule regarding good indexing strategies, if they are in any way worth their salt, they’ll always reply, “It depends…” This, of course, is about as useful as an umbrella wet and windy night in Dublin. But the presenter, the genteel Ward Pond, whispering sagely, managed to outline several phased strategies that, together with clever testing, could, almost certainly, obtain near optimal indexing. Quite a few sagacious, index related facts were discussed that I’ll save greedily for later posts I think. On his blog he indicated that yesterday someone had described him as the Chuck Norris of SQL in their evaluation, priceless.

Finally, the best is saved for last. If you, like I, have a towering regard for those poor Microsoft souls that toil, waving dead chickens, at blue screens of death and mysterious memory misbehaviour with little more than a copy of WinDbg, a piece of string and a Swiss Army penknife, you will of course know Tess Ferrandez’s blog. Tess is one of those voodoo programmers that use native debuggers to peer at the entrails of failing production code (an escalation engineer and aparently another Yoda fan). These tools are the epitome of low level. Frankly, cryptic ranks of hex addresses have lost their appeal for me since GUIs became all the rage.

Still I marvelled at the facility and obvious experience with which she shone the light of understanding, where once there had been impenetrable garbage. That’s a flowery way of saying she demonstrated some awesome skills. It’s plain to see that, short of a miracle, using such tools effectively may remain high art for most of us mere mortals. Still wild horses wouldn’t drag me away from tomorrow’s companion Interactive session.

For the real understanding and use of these tools, apparently a hands-on lab has been prepared. While avoiding tomorrow’s snoozy General Session on “Green” computing garbage, I’ll be trying to debug some poor snippet of software with little more than WinDbg and SOS (Son Of Strike, apparently).