Since I was doing nothing else on Monday, after the blog post below I spent a couple of hours going through the work in Visual Studio.

While I am still not sold on the concept of the tests driving the development process, it does make you consider your class design from the point of view of it's consumers.  Also the screencast did help bring some clarity to practical test design with NUnit, which is something I strugled with earlier.

My next problem with it:  How do we manage the problem that arises from programmers testing their own input validation for example?

Also the MVP pattern was easier to implement than it looked on DNR TV.  I look forward to watching the episode dedicated to it.

Maybe it's a hangover from a public holiday but I can't seem to find out from the system tables or sprocs.  Man it can't be that hard!

Google here I come :-(

Stay tuned for update if I find out...

So I'm catching up on some DNR TV with an easter egg and I'm watching the episode on Test Driven Development with Jean Paul Boodhoo [part 1 & part 2].  The obvious flaw -which they caughed to later- was trying to cover TDD, Interface-based programming with mock objects using NMock, and the model-view-presenter pattern, and an intro to ReSharper in one show.  Just too much new information.  Later they did a show on MVP (I am still to watch this...)

Anyway, it's clear the JPB is very capable at making this agile + patterns mashup work well for him, but I can't escape the common criticsm that it's just so much heavy lifting up front!   I'm prepared to accept that this work pays dividends, but they must accept that at first look this methodology looks to be the enemy of prodictivity, and that is going to be a very hard sell for regular mortals in the SME/ISV space.

The one idea I'd like to contribute to the debate is a what-if:  What if JPB & his freaky kind are just doing in long-hand now, what in future revs of Visual Studio we will be able to declaratively to get the same benefit with less effort?  Then, I'd be interested!

While on the topic of DNR, and DNR TV, the Dot Net Rocks! guys (I get the impression Carl specifically) have been on the bandwagon of using BitTorrent.  Makes sense when you are distributing content like they are.  They like µTorrent, me I hvae been a fan of Shareaza, because it's an open-source project rather than a commercial veture it has no problems being banner & pop-up free and has a seriously slick UI, but I just found out uTorrent supports RSS feeds that include .torrent files - perfect for having your DNR and DNR TV downloaded!

While on the topic of Carl, Pwop Productions, and their shows... Hanselminutes show #12 "Top Ten Utilities you Didn't Know You Had" is well worth 30 of your minutes.  Some old, some new, there has to be a time-saver in this bunch for anyone.

Obviously it's been too long between blogs for meso apologies for the link-fest and drifting between tangents... you may return to you're regular scheduled programming...

Getting back to normal on the network now.  New server for this blog, prompted by an exploded hard drive, evidence below...

Another thing I am seeing more of that requires some comment is poor requirements definition and specs for technical work.

An obvious benefit of a development team working to correct and complete specs is the output can be measured against the spec to give the project a logical and objective conclusion.

The other side of this is a healthy spec & requirements sesssion incourages the stakeholders in the project to actually think through their requirements.  Lesson: Don't take this for granted.

I've just seen a couple of notable examples of this lately when questioning a minor point in the spec has had the client say "Ah!  I didn't think about that!" raising more fundamental questions about the project.

I'm working on a throey that you can never ask the average guy what they want, because by virtue of being in the middle of their own business domain they are blinded to actually knowning the right answer.  You can only learn what they need.

After blog mint [?]:  Just more on that "ah!" moment.  I'm not saying it's a failing on the stakeholder's part.  It's natural and healthy part of requirements definition.  Just don't forget that it can (and will) happen.

I know what makes me sick and what makes me well, but that dosen't make me a doctor.

Knowledge of a specific business domain dosen't qualify you through some holy invocation to be a database designer.

Sounds like I'm taking a pretty hard line on this :)

Really it all stems from seeing people put in way too much effort to cope with bad ideas.  Take for example this pretty simple rule of normalization:

• Every time a row and column meet, that cell should hold one and only one bit of data.

Break that rule and you will be forever doomed to write hard to maintain queries.  I was just discussing a scenario that needed to  regularly update part of a field for a large number of rows.  Luckily that scenario isn't seeing the light of day <phew>

So, what criteria do you think should be on the test that issues licenses to develop databases?

Some possible reasons:

• VCs didn't learn from the first .com crash
• Technology pundits didn't learn from the first .com crash
• flickr 

Yeah, let the VCs and technology writers (with the exception of Robert Scoble) race each other to the bottom of the ocean.  Long live flickr!

Why I reckon flickr rocks:

• They blog.
• They know about Interestingness.
• You can get practically everything delivered over RSS.
  
• Tagging just rocks.
• You can upload straight from your Windows folders, or by email, or from OSX, or from iPhoto, or...
• The user experience is very nice.  Good implementation of AJAX.  Very clean UI.  Branding is nicely done.

So yeah, hype will always be there but if it was all for flickr, well, it wasn't wasted

(go on, give my flickr page a nudge...)

OK, this is my wishlist for a proximity security device for the Windows platform.  There are a couple out there, but none that do all what I want, and are available locally and are affordable.  Maybe no more than $100-150 initially and comming down with volume.

Backgrounder:  A proximity security device is just a gizmo that is aware of how close you are to your computer, and secures it when you're not around.

• It has to work with Windows integrated security.  This means not starting a new process that covers the screen and requires yet another local password store.  Nor somthing that starts the Windows screensaver.  It has to lock Windows at the NT Security later.  It should also be Group Policy aware, so your AD could stop your account being used on a machine that did not support the device.
  
• You're going to need a dongle on your keyring, and some receiver in your pocket, but No USB!  The system should not be able to be neutralized by ripping out the dongle while you're away from your desk.  Also USB leaves too much of the process visible to the driver stack.
• It needs to be tamper evident.  So if a machine is rebooted while secured it needs to be noted somewhere in big red letters!
  
• It needs to pause Windows Media Player/Winamp/Sonique/iTunes :)
• You must only be able to log in to the machine again when the dongle is in proximity.
• Maybe even some biometric on the keychain dongle so that it can only send back a signal when your fingerprint matches.
• It would be nice if one keychain could lock multiple machines.
• Lastly, and most importantly, it must automatically lock your machine when you move a certain distance from the machine with no questions asked.

Has anyone seen such a gizmo?  Or am I meant to keep dreaming :)

OK, here's my monthly props for CryptoGram...

Bruce Schneier links to a story where some Russians use a 'dead drop' technique via anonymous email systems like Hotmail.

The idea is that 2 or more people share an email account and instead of sending email messages to each other they just save their message as a draft email for the next guy to read. 

I like this as a specific case to illustrate the more general point about security based on "building higher walls" being bad becuase it assumes that all entry points are known!

After blog mint [?]: I've been thinking more about this... the key isn't that the message never went across the wire because it did (from the PC to the Hotmail server) but it's that it didn't leave Hotmail via SMTP, so the goal in sight is to avoid SMTP message detection and signal analysis based on SMTP traffic.  Taking that as the general case leaves open a bunch of other scenarios, like storing secret data on mobile SIM cards for example.  Just a thought...

This last couple of weeks I've been really getting into XPath, and SQL Server's sp_xml_preparedocument and OPENXML() syntax. 

I keep finding cool things to do with it but I can't see a way around the problem of sp_xml_preparedocument accepts only a local variable as the source document, which limits your document size to VARCHAR(8000) size -or half that for NVARCHAR.  I have not seen that limit yet in my work, but it still seems a little low.  What about ntext guys?

I'm gonna have some real-world XPath coming soon, this is just a pre-post warning :)

Apologies.  This site has been down more than up over the last couple of days due to some hard drive issues. If you are reading this... it's back up again :)

Great link from Jules: http://www.pbs.org/cringely/pulpit/pulpit20051117.html

If this is the future of the internet, count me in.

There is a new breed of imaging apps that have come up, at the moment I'm thinking of Adobe Lightroom (mac only, currently beta) and Apple Aperture (mac only, v1.0 and could use some polish).  The good thing is they are rethinking the UI for the specific tasks at hand.

But the old stalwart in this space is Photoshop (currently in 9th revision a.k.a "CS2").  So why does the world need both?

I think it comes down to the UI paradigm. 

One of the strengths of Photoshop has always been that it presents the user with a toolbox.  There isn't a button to make embossed text for example, however useful it might be.  The UI design expects you to know how to combine selections, masks and blend modes to create an embossed look for you text. 

This is a benefit not a limitation because PS is a creative application - your text bares the look of your experience and technique and matches the rest of the image perfectly.  If you want you can then record an action to make your own embossed text button.  Next to this, a generic embossed text button would give very average results.

The downside however is it requires considerable understanding of all the tools at hand to get the best results.

Compare to that the UI, or more the user experience, of Lightroom and Aperture.  These are focused on the needs of specifically digital photographers using high-end cameras (even one of these or these!) and pro workflow.  Because the UI is so focused they are able to encapsulate things that use to be a dozen clicks in Photoshop & Adobe Bridge & Adobe Camer RAW into one slick UI.  This is also a good thing.

So to examine the general case what does this tell us about UI design and user experience that can be applied to the applications we write?  I think it just underscores the need to directly address the outcomes the user is working towards in the UI, rather than having the UI just as a way for the user to interact with your program logic.

So look at your apps and ask... which UI are you; the toolbox or task-focused?