Here are my slides from the Richmond Code Camp 2008.1 talk concerning Silverlight.

Silverlight Version 2 - Hazzard - RCC2008.1 - April 2008.pptx (237.23 kb)

And here are some demo links that I used during the presentation: 

Deep Zoom
http://joestegman.members.winisp.net/DeepZoom/
http://www.neogeo.com/samples/SilverZoom/

Financial Management
http://www.cookingwithxaml.com/meals/financials/default.html

WeatherBug
http://sl.weatherbug.com/?zip=23060

Learning and Discovery
http://www.loc.gov/exhibits/earlyamericas/readingartifacts/

Image Snipper
http://silverlight.net/Samples/2b1/ImageSnipper/testpage.html

Form Controls
http://silverlight.net/Samples/2b1/SilverlightControls/run/default.html
http://labs.componentone.com/Sapphire/

These are the slides and source code that I used in my Richmond Code Camp 2008.1 presentation called "Look Ma! No Proxy!". This presentation concerns the problems related to proxy generation for traditional web services development. In this presentation, I propose a model for the future where proxies are no longer needed, at least not pre-built proxies as we use today. A bit of dynamic code generation, some C# client code and a bit of IronPython to glue things together. Mmm, mmm, good!

Look Ma No Proxy by Kevin Hazzard.pptx (197.46 kb)

ProxyGen20080426.zip (818.56 kb)

I found some odd behavior today with respect to the way that Silverlight's HtmlPage.Window.Navigate method works. If a page is cacheable by the client, calling HtmlPage.Window.Navigate will always choose to load the cached version of the page. With IE7, it does this without attempting a cache update check. Normally, IE7 will emit a cache update check for cached content, expecting an HTTP 304 response code, meaning that the cached version is up-to-date. However, when HtmlPage.Window.Navigate references a cached resource, it honors the cached content without checking for an update. This is how Firefox normally behaves and it threw me for a loop as a result. Check out the following code.

In that code, the first method call will cause the browser to use a cached page. This is true even if the cache-control was set to private, which is the default. It also does not check for a cache update as IE7 normally does. The second call injects JavaScript into the hosting page for execution. That one seems to force the browser to ignore the cache where the target page was received with the private cache-control policy. I don't know if this is a bug but I know it's not documented that way. I should mention that this happens on Silverlight 2 Beta 1.

I am about halfway through Clay Shirky's latest book called Here Comes Everybody: The Power of Organizing without Organizations. I've been tracking his writings since I read through Joel Spolsky's compilation called The Best Software Writing I. I don't know Clay Shirky personally but I'm going to refer to him as Clay in this post because it seems a bit less creepy than referring to him as Mr. Shirky.

This book is very good so far. The basic premise is that when "mass amatuerization" occurs, professions that had been previously created to solve problems often vanish with plenty of misunderstanding and resistence. As a software architect, I am sympathetic to the shift that social computing brings to my world-view. In fact, Clay references Tim O'Reilly's article entitled "The Architecture of Participation" in the book. There's the A-word. That's my job, right? I'm the software architect.

But as Clay and Tim point out, the architecture of a thing is as much defined by what people do in response to a problem as it is defined by what we, the professionals, decide will be done about it. How many times have you designed a great piece of software only to find out that the users are still tracking artifacts in your system using a spreadsheet? They're mailing the spreadsheets to one another as an ad hoc version control system. It's maddending, right? But this common example shows that when the cost of creating your own solution to a problem falls below what you would pay professionals to build it as you conceive it, the professional's job evaporates or becomes marginalized. Clay draws some relevant analogies in the book including how modern print newspapers cannot compete with bloggers and how Bible scribes couldn't compete after Gutenberg invented the printing press either.

While modern newspapers are struggling in the wake of the mass amatuerization of written words, newspaper owners should be looking to the other analogy that Clay wrote about. While it's true that the Bible scribes were essentially wiped out by the mass amatuerization afforded by the printing press, what replaced them eventually evolved into a wide range of new professions. Of course, modern journalism and all of the related newspaper professions are counted among them. What Gutenberg's invention did was to expose that the need for printed words was much larger than the output that the professionals of the period could produce. Now, the same thing is happening to the newspapers. The once bifurcation or trifurcation (is that a real word) of the readership has been exposed as a polyfurcation (now, I know that's one's not real) of interests and opinions.

I don't take the paper anymore. I don't watch the morning or evening news, local or national. I don't even listen to the local radio stations. I just don't like their bent, if you know what I mean. But I do read a few blogs and listen to a few podcasts every day. And I will occasionally pop over to CNN, Fox News or the BBC websites to get their spin on a subject. The point is that my lifestyle as an information consumer has evolved into a sort of digital mashup of daily activities rather than committing to the Post or the Times as my single source of information. Of course, modern newspapers are not single sources of information. They draw content from dozens of sources and hundreds of writers every day. And that may very well be what allows them to survive in the blogosphere of the future. The ability of the traditional newspapers to organize and deliver those mashups for me may create a whole new profession of content aggregators (not editors) who know me, know what I like, know what I find provocative, funny, call-to-action, etc.

What about software development? What can we learn and how can we adapt early to the coming changes? Google Apps, the Facebook Platform, Amazon Web Services and dozens of other APIs are emerging nowadays that allow average users to build usable software on their own. Should we be as worried as the Bible scribes should have been in the wake of movable type systems? Maybe. But we have many advantages that the scribes didn't have. Among them, thanks to print, broadcast and Internet media, we can perceive the threat more quickly than it will spread, before it can mature into a set of new, competing professions. Secondly, mass amatuerization is creating a lot of really bad software today. That's not to say that there isn't a lot of bad software out there already. It's just that when we look closely at the fundamental problems that created our profession, there are some obstacles that Google, Facebook and Amazon will be hard pressed to handle. For example, how are exceptions reported and managed across a Franken-app (an application whose body parts come from different vendors)? Certainly, Dr. Frankenstein realized that this hand needs to communicate with that arm. So I had better get the nerve endings just right. The players in the mass amatuerization of software today aren't thinking that way... yet. And what happens when the network cable is disconnected? Adobe Air is answering that latter question fairly well but Adobe's platform competes with Google's which competes with Amazon's, et cetera, et cetera. While they are all too busy competing with one another to form a unified front, we have a little time to plan.

I think the best thing that software professionals can and should be doing today is introspecting about what Clay calls the scarcities that create a profession. In the print media analogies so far, there are always those who have emerged to define the new scarcities that exist in the light of new paradigms that pop up. Those people become leaders in the new space because they have expended the necessary energy to define, provide for or in some cases to create the scarcity that makes a new profession valuable to consumers. What scarcities exist in the emerging software development models that will translate into positions of leadership in this next century? I have some ideas on this subject which I will be writing about soon. Until then, read Clay's book and let me know what you think.

I do a lot of demos: training, teaching, mentoring, etc. I get asked about my Visual Studio fonts and colors quite often. I use Tomas Restrepo's Nightingale scheme for Visual Studio 2008. Here's the link to his VS Color Scheme page. Scroll down to check out Nightingale and other nice schemes he's made available. I like the contrast of Nightingale and how colorful it is. I use a different font though called DejaVuSans Mono. It's clean and compact yet bold.

Here's a screen shot of the Nightingale theme with the DejaVuSans Mono font that I use. By the way, setting the vertical guidelines that you see in the image below is done through a registry hack. See the REG script below if you're interested.

Save the text below as a REG file, then right-click on the file and select Merge to update Visual Studio 2008 to show gridlines at positions 4, 8 and 80. Of course, if you want vertical guides at other positions, change the Guides string to your liking. Visual Studio 2005 respects this setting, too. Just change 9.0 to 8.0 in the path. Here's the REG merge script:

Silverlight is a pure client technology. So, it has nothing to do with your SOA strategy, right? Not so fast. While most Service-Oriented Architectures try to remain agnostic about the clients who will approach the system, you can't be totally ignorant of the constraints that clients might impose. There are many "potential" requirements that architects have to think about. For every requirement that gets written down, there are usually two or three other implied requirements that never get expressed on paper. Architects just make sure that the plumbing of the applications help the developers to handle these cases when they arise. Of course, this is why WCF abstracts the concept of bindings as well as it does. Being able to expose any WCF service through a variety of tuneable, standards-based and proprietary bindings is one way that an architect can remove some rigidity from the system.

Silverlight is interesting because it exposes WCF client classes like ClientBase<T> and ChannelFactory<T> to a class of users who've never drunk from the services well before, so to speak, at least not directly. There is a notable exception from Microsoft in the not-too-distant past. Remember the DHTML Web Service Behavior? This was an HTML Component (HTC) script published by Microsoft just as XML Web Services were beginning to become popular. It used the XMLHttpRequest Object exposed by the browser to allow client-side script to invoke web services using WSDL and SOAP. The HTC would automatically download the WSDL contract for a service and build dynamic objects to expose the service and its operations at runtime. What an incredibly simple and powerful tool that was! It didn't support anything but simple data types for moving information between the browser and the server. But, when you have a XML Data Islands and a JavaScript Base64 codec on the browser, there's not much data that can't be expressed as a string.

I wrote many applications using the DHTML Web Service Behavior before the term AJAX appeared on the scene. Maybe this why when AJAX started to become a movement, I wasn't all that impressed. It seemed like old news to me. I remember how I designed those services. I took great care to make sure they were stateless and load-balancer friendly. I set up security protocols that would detect and prevent malicious activity. I had all sorts of profiling and logging code in there. In short, I treated those services with the same care that a good architect applies to any real web service. However, when the AJAX movement started, a lot of the scrutiny that I would have applied to real web services didn't seem to be in fashion for the many AJAX callbacks flying about. Those AJAX callbacks were somehow second-class citizens from an architectural point of view, not because I wanted them to be so but because many of the developers encapsulating callbacks into their AJAX controls didn't think of them as real service calls. And because it was up to developers, not architects, to drag and drop AJAX controls onto a design surface, the attention just wasn't there to do what was right in all cases. Hence, a lot of poorly-structured AJAX applications were written (and are still being written today).

Today, REST and POX are becoming popular for accessing web services. This is due, in large measure, to the rise in popularity of scripting languages and the somewhat duanting complexity of WSDL and SOAP. However, Microsoft proved that SOAP 1.1 could be handled via JavaScript as described before. And you can imagine that a company like Microsoft, if it decided to pursue the refinement of its DHTML Web Service Behavior, would have been able to handle the dynamic creation of data contracts via JavaScript, too. The problem wasn't the service contracts, operation contracts, fault contracts and data contracts. The real problems with dynamic, JavaScript proxies are security, reliability and transaction management. Those are the things that differentiate SOAP from all other forms of web service access today.

Back to the premise. With the WCF client classes moving to millions of desktops via the web, there's a shift coming in the SOA world. This creates for the first time what I call the Web Desktop. Being able to extend standards-based security, reliability and transaction management to the Web Desktop means that architects will feel more comfortable moving their SOA strategy up the stack. This is a very good thing. Most serious software developers love and hate the web. The deployment model is great but what's good about it sort of stops right there. HTML and JavaScript are just awful mediums for expression. And what about debugging client-side script? Nothing short of a nightmare, that is. It's no wonder that it's taken this long and hundreds of millions of dollars of research and development across the industry to get decent DHTML/AJAX applications into circulation. Event still, the quality and reliability of those applications across so many browsers and platforms is often sketchy. And the cost to implement such an application and properly test it is out of reach for all but the wealthiest companies.

The coming changes due to WCF support in Silverlight probably won't be cataclysmic but the changes will offer useful new ways of thinking for solution architects and developers who understand how poorly all of us are exposing applications over the web today. To dampen the spin a bit here, I should tell you that the Silverlight 2 Beta 1 is still a bit weak on the WCF front. It has near nil support for metadata exchange and only supports the BasicHttpBinding. But Beta 2 promises many improvements. Stay tuned.

I attended the Speakers Forum for the Richmond Code Camp on Monday evening. Tim Tatum presented a talk on Presentation Development and Delivery. It was very good. Tim put this together in an effort to get the speakers for the Richmond Code Camp 2008.1 to be prepared better than they have been in the past. Don't get me wrong, the presenters at the previous Code Camps in Richmond have been very good. But there's always room for improvement, right?

Tim brought a decade of experience teaching in the public school system and another decade of work in the IT field to the game and it showed. Very well done. We had an open discussion at the end where we opened up the floor to all sorts of ideas which was icing on the cake. If you want Tim to deliver this presentation to a group in your area, drop a note (kevin at gotnet dot biz) and I'll get you connected to Tim.

Another resource that's good on this subject is a new book by James O'Rourke entitled The Truth About Confident Presenting. I have it on my Safari Bookshelf and have been getting lots of good nuggets about prsenting from it, too. It's organized into 51 truths that you can bite off individually, treating it like a reference. I like that style of organization in any book. It's especially good for this subject. Here are the book details:

Cross-domain WCF service calls from Silverlight are nice to have. But I don't see them being the norm for most Silverlight controls mainly because most of the time, we'll want to keep the services exposed from the web tier in lock-step with the Silverlight controls that consume them from a deployment standpoint. The simplest way to do that is to treat the WCF calls that come from the browser like any other web page or callback that the browser might consume. This will avoid having to inject a location into the container (page) for the Silverlight control or from having to use an external service locator to find it.

OK, so assuming you have a rule requiring that every service object will be located relative to the pages hosting a Silverlight control, this little bit of Silverlight code will build an EndpointAddress that targets a service called MyService.svc in the same virtual directory:

You'll need to import the System.Windows.Browser namespace to use the HtmlPage class in this way. As you can imagine, the static Document property on the HtmlPage gives you almost full access to the DOM for the containing page. We're just using the DocumentUri property of it to find out where the hosting page emanated from, lopping off the page name and adding the service (page) name. When you're debugging with the Cassini web server which assigns port addresses dynamically, this is a nice way to make sure that you always connect back to the same server instance that served the current page.

In the TDD frenzy and hype these days, it seems that many developers have forgotten the importance of building good debugging skills. In fact, I know one fellow architect (whom I won't mention by name) who brags about not having used a debugger in years. He claims that his code is so well tested that he doesn't need a debugger. Funny how, when I found a bug in his code recently, I isolated and fixed it using a good, old-fashioned debugger.

Don't get me wrong. I think TDD is great. But there's no substitute for stepping through your code and watching it work. It slows the process down to do it but that's true of TDD in general. I am thinking about hosting a debugging workshop in the Richmond area soon. If you're interested, drop a note to kevin at gotnet dot biz and let me know.

I attended the Richmond .NET User Group meeting this evening. Craig Adams of Vivus Software presented concerning ClickOnce application deployment issues from the real world. It was a good presentation. Although I know quite a bit about ClickOnce deployment, I learned a few things at the meeting. As I sat there, listening to Craig, I couldn't help but think about how Silverlight 2 packages its XAP files to include an application manifest. Certainly, the CoreCLR and BCL in Silverlight aren't as full featured as what the full CLR and FCL provide. And the range of deployment options in ClickOnce is good for system administrators and who need finer control over the process.

But I found myself thinking about how simple Silverlight 2 deloyment is. And now that we have the Silverlight Controls in Beta 1, how long will it be before we start seeing mass migration to Silverlight for doing what we once would have used ClickOnce deployment? At SnagAJob.com, we have one tool that we developed as a ClickOnce application because it was just too hard to build as a web application. So, we have this fantastic web application for our employer community with a hole where the ClickOnce application would go if we could make it run on the web without a lot of effort. So, we are actively porting it to Silverlight right now and I suppose we will retire the ClickOnce application as soon as it passes QA.

Personally, I'm excited thinking about a web-centric world where the browser can easily host rich, interactive forms that run my C# code on the desktop. I understand the glitz and glamour of Silverlight as a media-savvy presentation engine. But if I can get it to do Windows Forms cleanly and easily, I'll be very happy. Let's face it. Web development is just terrible today because HTML and JavaScript are awful. I tell people all the time that if I had to write HTML and JavaScript every day, I would find another lineof work. Using C# and XAML on the desktop through the browser is the best idea in computing in the last decade, in my opinion.