New posts over at TestHarness.org

Check out some new content from me over at TestHarness.org

Silverlight as the View of Full-Trust applications

I recently read a great post by Ward Bell on “multi-headed” platform development…making your app work with WPF and Silverlight.  This is a topic that is of interest to me in the enterprise setting…and I have done a little playing around with it.  I left a long-ish comment on his blog with an idea that I’m hoping to get feedback and opinion on, and so though I’d repost here with the possibility of getting other’s ideas.

Wards post is here: http://bit.ly/Swy1n

Here’s my thoughts:

In business apps, generally the argument for writing something in WPF is to have the local access to services (printer, hardware etc), not to get “3D” and other WPF niceties. Silverlight 3 (IMO) is ready for LOB app development…more than ready.

— IDEA —

So, if that is the case (which I believe it is), for the “I need a bar code reader” type scenarios I’m considering an approach where you “host” SL within a rich-client container, and through a JavaScript bridge access your full-trust code which is locally installed. You app is installed locally, you have full-trust assemblies, so can do the local manipulation of the system or access to printers, scanners, barcode readers etc.

[NB: This is not the same as the FIT client install, because your getting access to a full-trust installation that you setup. The FIT client install is still in the sandbox]

This would essentially boil down to having the local, full trust container look-n-feel like a service endpoint…you’d be making calls to methods by serializing parameters (via DataContract) and passing them through JS as strings. Far from this being a down-side, I could see how this might force good architectural design…ensuring the UI really is View…and not tangled up with stuff that should be there.

Now, the hypothesis (unproven at this stage) is that the effort of setting up this container (once) would be less than the ongoing development friction and maintenance woes of cross compilation and incompatibilities that Ward describes. You also get the ability to use the same UI (or parts of it, if it’s nicely modularized a la PRISM) in the browser – and instead of accessing the local-full trust code via the JS bridge you hot-swap to calling a web-service.

—

I would love to hear people either beat up on this idea and tell me why this is crazy, or offer other opinions and insights.

I’ve done a bit of dual-WPF/SL development (mainly building out PRISM examples) and it’s has a bit of a smell to it. I’m optimistic that a surgical containment strategy may be a smart move? What do you think??

Silverlight Development Dashboard

For as long as I can remember, my approach to UI development has been centered around carving a UI up into it’s logical pieces (“controls” you might say) and hosting them in some kind of test harness, where I can manipulate their API’s as I continue to craft them.

I’m sure this is common practice…it’s such an obvious thing to do.  I think it’s possibly not as wide spread as it might be as it’s a lot harder to do in the web (with HTML) than it is with a rich client….until now that is (read on to find out why).

For me the important design goals when building a tool to assist here are making this both ridiculously easy AND the outcome permanent.

Permanent in that the tests hang around.  All too often make-shift harnesses are erected while a control is under development, then thrown away, abandoned or lost.  But unit-testing taught us that having a long lived set of tests that can be run at any time (and often) provides increasing returns over the long run.

And Easy in that it’s simpler and faster to build your control this way that it is hacking anything else up.  It needs to be no trouble so that you actually do it.

For me, with UI it’s turtles all the way up and all the way down. “Controls” can sit on a spectrum anywhere from super primitive (a button, a checkbox) up to the root of the application’s UI…the super aggregate of all controls, and all modules that make it up.  I like to be able to bring up any piece of the UI – strip it’s behavior away, or turn it back on, hand it a mock, prod it and pock it.  This in the same spirit that leads one to the set of patterns represented by the “Composite Application” approach (or see here for a great set of tool and guidance to this).

Now, you may of course be be much smarter than me (you probably are), but if I can’t do this, if I can’t factor out UI development in this clean, super decoupled fashion, I just know where I’m heading, and heading fast…..to a horrific realm of fear and loathing.

But the world need not be such an ugly place….no! Not if you have a “Development Dashboard” (this the fancy name my friend John came up with for “Test Harness”).  And with the advent of Silverlight I’ve been at it again…building a test-harness to make building beautiful UI easy and fun and joyful, and I’d like to share with you some of this work-in-progress.  Here’s what it looks like:

The approach of writing visual-tests against a UI control enduces many of the benefits found in classic TDD (or BDD), only with the particular slant being on UI componentry.  It’s the same basic mind bend going on, namely: write the code that consumes the system first, then write the actual system.  And the wonderful miracle that occurs from this seemingly counter-intuitive move is that the emergent code just tends to be cleaner, lighter, more de-coupled, and more sensible from the user’s perspective… In other words, better designed.

[Please note, by “user” here I mean the next developer working with the control…I’m not saying anything about the interaction-design or usability…that’s another story].

To get a test up in the Dashboard, all you need to do is adorn it with an attribute [ViewTestClass]

The ViewTestClass attribute signals that this is a class that contains tests to host within the Dashboard.  The developer then selects the assembly that contains the test using the Dashboard’s Module Chooser:

The assembly is now loaded into the dashboard, and our new ViewTestClass name ‘MyControlTest’ is listed.  Notice that we did not have to muck around with configuration files and mapping or anything like that.  We just created a simple class using minimal native syntax the developer is used to, and whamo, it shows up…no fuss.

Also, now that this assembly is loaded, the Dashboard remembers it as a possible point of interest to test with, and stores a reference to it making it available each time the dashboard is loaded.  It does not, however, load the assembly into memory until a test control is asked for – important for saving resources and keeping the experience light and fast.  When the assembly is no longer under test it can be removed by using the “Eject” button.

Once the ViewTestClass is selected, it is added to the ‘Recent Selections’ list.  As you know, the development process is a loop of micro-iterations.  Write-code => test => write-code … (repeat).

The last set of test classes is positioned in a stable part of the screen, the “Recent Selections” list.  Muscle memory kicks in, and no cognitive friction is incurred getting to the test control of interest, meaning the developer can remain totally in the flow with their UI problem.

Now, here’s the interesting part.  To get a control into the test, we simply add a method decorated with the [ViewTest] attribute.

The type of the parameter, in this case a ‘Placeholder’ control, determines what control will be hosted within the Dashboard’s test surface.  With this ViewTest in place we now have this to work with:

The ‘My Test Control’ becomes a clickable option, and the control we are testing (a ‘Placeholder’ control which is our arbitrary example) is shown on the test surface.  The test method would typically manipulate the control is some interesting way, exercising the API and allowing the developer to see what’s going on, what needs fixing, and what next creative moves to make.

At this point you may also create a View-Model instance and bind the control to it if you’re using the MVVM design pattern.  You can inject stub model’s into the V-M, and generally engage in the full gamut of testing-goodness.

If we need to test more than one control at a time, because we’re interested in the interaction between multiple different controls, we simply add more parameters to our test method.

…and the Dashboard lays them all out in on the test surface.

MVVM described by Fowler (as Presentation Model)

A great design-pattern description by Martin Fowler entitled “Presentation Model”.

In WPF/Silverlight terms, this would be MVVM – and is a great statement of what’s going on.

http://www.martinfowler.com/eaaDev/PresentationModel.html

Thread Safety in a (Property)Changing World

 

I’m really loving the power and simplicity of MVVM (Model View View-Model).  The View-Model communicates changes to the binding system via the ‘PropertyChanged‘ event of INotifyPropertyChanged.  I also like to communicate changes from the Model to the View-Model via this event.

But there is a potential rub here.  Whenever you do some work on a background thread, you need to make sure you pass execution back to the UI thread if the resulting activity ends up changing the UI (a foregone conclusion really when firing PropertyChanged).  It’s a real drag having to invoke the Dispather whereever you know (or suspect) firing the event will cause a threading exception because an attempt is made to update the UI on a background thread.

Well, after poking through Nikhil’s excellent framework/sample – I found a great way to remove this drag from my life (and your life) forever!  Below is a base class you can use to derive model’s and view-models on that will always fire the PropertyChanged event over on the UI thread.  Dispatcher arbitrage is now a gone-burger.

 

 

And for good measure, here’s an asynchronous unit test that verifies this behavior:

 

Office in Silverlight…I thought so!

Well, it’s been so shockingly long since I’ve been posting that I only have to go back four entries to point out a prediction I made ways-a-way back in Oct 2007:  Office will port to Silverlight (or words to that effect).

I know, scrolling 4 posts down is going to be cumbersome, so here’s a link too.

Well, it seemed obvious back then to me, and now it turns out it’s well on it’s way.  Here‘s a somewhat limited video on Channel 9, but there’s enough in there to see what’s a cookin.

http://channel9.msdn.com/posts/PDCNews/First-Look-Office-14-for-Web/

Big emphasis on the real-time collaboration aspects, which is the right thing to do of course.  But what’s interesting to me is in the demo they only showed editing in Excel and OneOne, not in Word.

Why?  Is this too hard to do?  The RichTextBox has not been developed for Silverlight yet (although some 3rd party ones have sprung up recently).  I assumed MS was staying clear of RichText for the same reason the browser editing control (IMO) got stunted in it’s development ascent….so that it wouldn’t compete with Word.  So, what’s going on?  Is it just that it was an early demo and they hadn’t done it yet, OR is the editing surface fundamentally too hard to replicate in Silverlight, OR are they making it a read only experience to avoid other nasty competitive issues by having that technology developed and floating around in Silverlight land?

Most important to me is that this shows large commitment my MS to Silverlight, and that it will become a dominant platform in line-of-business, enterprise app space. And, of course, that the platform is grunty enough to support some serious interaction developments.

History of the Internet

Here’s a wonderful history of the Internet in a visually light and delightful form.

http://vimeo.com/2696386

I’m not sure about the initial impression given of mainframes just before time-sharing kicked in.  It wasn’t a step back to go to mainframes, because there wasn’t any kind of accessable ‘interactive’ computer prior to that…it was all punch cards, which was shockingly hard to develop in from all accounts (and no Google…how did they do it?).

On this general theme of computer history, one of my favorite reads of late was:

What the Dormouse Said: How the 60s Counterculture Shaped the Personal Computer

Typically accounts of modern computer history (the PC) start at around 1970 with Apple and the usual suspects. What is interesting about this book is that it concentrates on the 2 decades prior to this, and details the pioneering work of Englebart (Human Augmentation Lab), McCarthy (SAIL, Stanfard Artificial Intelligence Laboratory) and a slew of other characters that emerged from the 60’s counter culture and shaped what became one of the most significant developments in modern history…the “personal” computer.  What’s exciting about this read, for me, was that by all account many of the pioneering ideas have yet to be implemented.  Certainly Alan Kay said the same thing to Doug, Scott and I as we drove him up to LAX last year, “go back and read Englebart!  It’s all there.”

Hometime

Mapping Concepts

“As indicated earlier, we defined concept as a perceived regularity (or pattern) in events or objects, or records of events or objects, designated by label. It is coming to be generally recognized now that the meaningful learning processes described above are the same processes used by scientists and mathematicians, or experts in any discipline, to construct new knowledge. In fact, Novak has argued that new knowledge creation is nothing more than a relatively high level of meaningful learning accomplished by individuals who have a well organized knowledge structure in the particular area of knowledge, and also a strong emotional commitment to persist in finding new meanings (Novak, 1977, 1993, 1998). Epistemology is that branch of philosophy that deals with the nature of knowledge and new knowledge creation. There is an important relationship between the psychology of learning, as we understand it today, and the growing consensus among philosophers and epistemologists that new knowledge creation is a constructive process involving both our knowledge and our emotions or the drive to create new meanings and new ways to represent these meanings” – Source

Concept maps are a fascinating alternative to mind-maps. I live in mind-maps, but am branching out into concept maps. What is interesting to me is that whilst mind-maps quite often become idiosyncratic to their creator, and are more an aid in personal thinking that in conveying data, concept maps play a surprisingly effective role in conveying information in educational settings. They have their theoretical roots in the work of Joseph D. Novak working at Cornell University in the 70’s. The paper sited above is a very interesting discussion on the research and theory behind concept maps, and how to effectively create them.

Here’s an example of one I just created. Seasoned concept-mappers may notice problems with my form here, but it’s a start. You read the map from top to bottom. A boxed item is a “concept”, and a boxed item with one or more named arrows is a “proposition”:

Towards a total eclipse of the desktop

The new version of Outlook Web Access is a freak of nature. It’s so good it’s astounding. ASTOUNDING. The skill required to pull this feat off using blunt tools like the HTML DOM, AJAX and JScript is awe inspiring:

This will (I predict) be redone in Silverlight 1.1 when it’s released…and from there some interesting thoughts arise:

1. This could eclipse the native Office experience.  It easily could.
2. And if so, this would beg the question: why doesn’t the entire Office suite get redone in Silverlight?

I think it’s inevitable that a rich Office experience is delivered in Silverlight…one day. But seeing Outlook Web Access, and the obvious development path they’ll take towards Silverlight, this could accelerate pace towards that day when we’re really using Office in a browser (and actually liking it).

This radical departure from a client install might also offer Microsoft the perfect excuse for why, when rewriting Office from the ground up, it’s feature set is cut-back. People would wear that because it’s a “new” product…not an “downgrade” wearing “upgrade” clothes. Who knows, we might even get some collaboration tools in there that aren’t embarrassingly hacked on afterthoughts atop that smoldering pile of old code.