Marc Adler posts about how he sees the work Microsoft is doing with Sea Dragon as the next generation of heatmaps. I'm not sure I see a direct connection, but I can see how this could have the same depth of impact on UIs as heatmaps do.

I have played around a little with PhotoSynth, and while I was fascinated and spent several hours I didn't have exploring some of the photosets, I didn't make a connection to anything I do.

What did cause me to make a connection was the possibility of an infinitely zoomable UI. The TED video Marc linked to shows some examples of zooming into an ad in a newspaper, seeing some fine print with additional information, zooming into that, seeing more fine print, zooming, etc. I thought that was really amazing.

There are a lot of UI metaphors common in software that kind of all dance around the restriction that you can't zoom. Instead of Two-Panel Selector (what I always refer to as "Master Detail"), for example, you could have Zoom Drill-Down. Instead of tabs for different categories of information, how about boxes that you zoom into to see details.

I can't wait to move to a UI technology that enables this sort of UI metaphor. I want to play around with building zoomable interfaces.

Here is a video showing how easy it is to host Power Shell in a GUI. I tried to show this in my Code Camp talk last month, but this is much more focused on the task of getting power shell hosted in your app. 4 minutes and your good to go. Excellent stuff!

I mentioned this in my Code Camp presentation, but PSCX rocks! They just released a new version that has a feature that has a new alias I am going to love: "su" for elevate. This really nice when running on vista with UAC. This was one of my big problems with Vista ("what do you mean I can't start the SQL Server service?!?!"), but now I'm good to go. Thanks PSCX team!

Ayende mentions, "Working Effectively With Legacy Code." This is also one of my favorite books. I read it just before starting my current job, which was  kind of good timing.

I see this book as kind of a self-realization kind of thing - no matter how good of a developer you are, at some point while reading this book, you will realize, deep down inside, it's not just other people writing legacy code - you're writing it too. What are you going to do about it? Legacy code is all of our problem. It doesn't help to blame people, because we're all to blame. It's only legacy code if you can't change it and make it better. Blame isn't a part of making it better.

It's very healthy for people to have these kinds of realizations every so often. We all need it.

I, like everyone else I'm sure, am currently in the midst of dealing with some legacy code (LDI). At the same time, I am thinking about some changes to a project I'm in charge of, but had to put down for a while recently (Select Holdings).

One of the big themes in Feather's book is breaking dependencies. Repository and Service Locator are great patterns for this. I particularly like the implementation Ayende has built in Rhino.Commons. There is a kind of Service Locator class called IoC, which makes it drop dead simple to pull out "new"s from legacy code and make them services. This plus his Repository<> class, which is built on the IoC class, help get services and entities injected into dependants with absolute minimum change to the dependant code - i.e., no new constructors or properties to add, and the corresponding ripple effect that has on the code you are trying to work on.

For example, one of the classes in the legacy code I am inheriting is kind of a gateway for a third party service we pay for. I really want the interface code - it does all these nice things like RPC over FTP and translating weird file formats - but it has about a dozen yucky dependencies on some code I have no time to maintain. I am talking about lots of speculative generality - six classes necessary to represent "price" in the domain model. Plus lots of static methods.

My refactoring steps become:

0. Write some lame tests that actually call the third party service and inflate our bill, since there are no existing tests to speak of. 

1. Replacing new's with with IoC.Resolve<>() and Repository<>.Get(). This works especially well in cases where there are a ton of static methods.

2. Test. Last test we have to pay for.

3. Extract Interface on the dependency. Replace IoC.Resovle<SomeService> with IoC.Resolve<ISomeService> (the interface).

4. Use Rhino Mocks to mock the interface.

5. Test.

6. Build new simple implementation of replaced service, this time with tests and better design. No more changes needed to refactored gateway code that I want to keep. If I do need to make more changes, at least I have tests now.

I keep hearing the "Six-Million Dollar Man" theme song playing in the background. That's what this feels like. Instead of the despair of, "Crap! I have to maintain more legacy code that I didn't know about!" around every corner, there is the positive thought, "We can rebuild him. We have the technology. We can make him better than he was. Better...stronger...faster."

John Paul Boodhoo is doing a boot camp in Wenatchee in August. I really wish I could go, but have already used up my employer issued training karma for the year. Maybe some other Southie will go?

It's really hard to find courses and training that isn't technology specific. Believe, me - I tried. But this looks like a totally fundamentals, you'll-be-a-better-all-around-developer-after-attending, kind of deal.

I think SQL is the assembly language of the data world (i.e. the wrong level of abstraction for most problems), but I really enjoy low level details about how things like SQL Server work, internally.

A few years back I read Ken Henderson's amazing, "The Guru's Guide to SQL Server Architecture and Internals" and was amazed at how much it helped me understand SQL Server and Windows in general.

This morning I found this weblog, via Jason Haley, which has bite sized (or, actually, large meal sized) chunks of SQL deep knowledge. My head hurt after the first few posts. Ouch...ouch...ouch...

This is depressing:

I try really hard to _at_least_ read the stuff in my A folder, but I can't keep up with Ayende.

I've noticed recently that I'm getting better at learning from videos and worse at learning from books - that is to say, I am becoming an illiterate television viewer.

Hmm...illiterate...Let's call it "post-literate" to make me feel better about myself.

There are several good videos I've seen on things as diverse as WF and ASP.NET AJAX to Agile techniques and architecture (I'm trying to convince my family to switch to dnrTV for Movie Night, just to catch up with all the great stuff they have there.)

Recently I had a conversation with my buddy Michael about CSS Layout.

Yesterday, I saw a link to some lynda.com (lynda as in Lynda Weinman, the one Scott Hanselman interviewed at Mix07) videos on Expression Blend from Jason's Haley's Interesting Finds.

Still with me? (sorry for all the links, but this is how I usually find out about stuff, and I want to give credit to those that built the path)

I installed Expression Web several months ago, and it's starting to collect dust, so I decided to check out what they have on Expression Web. They have a pretty good looking set of videos, but I need to see about getting the boss man to get me a subscription (on the // TODO list) to watch the whole thing.

After watching the first part of the lynda.com series, I wanted more, NOW! So I searched for some free videos, and after watching about half an hour of slickified marketing videos, I stumbled upon these, which I am linking to here to keep _you_ from having to watch half an hour of slickified marketing videos.

Phil Haack has an excellent post that strikes a nerve with me. I too often find a surprisingly large gap between controls in place for code developed by developers and controls (if any) in place for code developed by other users.

I find that, to an alarmingly large degree, steps and procedures in the Fort Knox model of software deployment are reactionary - one bad thing happened once, and as a consequence, we have to do extra work of questionable value every time we need to update software. After a while, magical properties are attributed to the sacred process and no one really remembers the reasoning behind them well enough to maintain them. It becomes ceremonial.

A process is just like a piece of software - once no one knows how to maintain it, it begins to decay.

In reality, the right solution for these problems is probably somewhere in the middle, between Fort Knox and anything goes.

Before we tackle processes for controlling change across the enterprise, we need to take a critical look at how we tackle these problems. If we have people blessing Excel documents or better blame attribution tools, will that really prevent people from making mistakes? It doesn't seem to work all that well for software, so why would it work for other problems?

Maybe the Agricultural Bank of Namibia is in hot water because they made bad business decisions. Maybe financial services firms are in hot water because they are thinly staffed and, as a consequence, poorly managed. Maybe these aren't mistakes at all, but people acting maliciously or on bad information. 

If we add process to this, I don't believe it will necessarily improve the odds that mistakes won't happen. Maybe they should do pair spreadsheeting? I don't know, but my hunch is that these aren't problems that can be fixed just by version control or QA.

Get them here and here. [via The Power Shell Guy]

I love the fact that Richard Cambell has machines named Terrence and Phillip...and they look pretty kick ass.

If there were such a thing as hardware p0rn, Richard Cambell would be Hugh Hefner.

Not that I'm a fan of the web 2.0 idea, but this is a cool video.

[via Daniel Chait]

Check this tool out.

For my powershell talk at PDX Code Camp I originally wanted to show a power shell provider using Cecil to expose the types in a .NET assembly. Alas, like everything else fun and interesting, I never got it finished enough to show at Code Camp.