On the Mark: 2/15/2002

	Friday, February 15, 2002

Sam Ruby's Busy Developer's Guide to WSDL is officially really cool in my book! I followed his example to build a WSDL file for a more complicated service I have implemented in Radio (one that returns an array of arrays). I had trouble with Microsoft's WSDL tool not processing the import statements correctly (too bad, I thought those were a big help in isolating complexity). Other than that, it all worked great. I generated a C# wrapper using the WSDL and then created a client class to use it and process the results. It Worked!!!

I have more work to do. I left the return type as anyType on the result. That resulted in an XMLNode being returned to my C# client. I would like to get that straightened out so the desired array is actually returned. Nevertheless I am off and running with Sam's expert guidance. Where shall I go today?

Note: I am not sure that I am wild about going through this process for all of my SOAP services implemented in Radio. However, Sam has shown that taken piece by piece the work is not terribly complicated, just tedious. Since Radio is good at tedious stuff, it should be possible to build a tool that takes care of much of the tedium. As Dave Winer has often pointed out in the past (sorry, no link available at the moment), we will never be able to generate the type information. If that is the only part I have to craft by hand, however, then maybe I can accept regularly using WSDL to describe Radio implemented SOAP services.
6:47:24 PM [Macro error: The file "D:\Program Files\Radio UserLand\www\#prefs.txt" wasn't found.]

Communication Ever since the Tower of Babel incident it has been communication that has separated man and antagonized his relationships. It is not even a matter of language. How many times do we hear two people arguing only to find they are both in agreement! "We are two people separated by a common language" my old friend John Goularas often says.

I believe communication is a critical skill for any software developer involved in design work. A heads-down coder may be able to get away with lesser communication skills, but not somebody that needs to convey an understanding of a problem, and its potential solutions to both clients and to developers. A key skill I look for, and expect, from a software analyst/designer is the ability to separate the What from the How. That is, clearly specifying what the business problem is independent of how the problem will be solved. It is a simple notion and one that is so fundamental to the design process that many of us have simply forgotten about it.

One guideline that can help with this separation is to always be thinking "if somebody else were to pick up this project tomorrow, will they be able to understand the problem to be solved based on my analysis?" or "does my design accurately seperate the approach (call it a design philosophy or design solution) from the implementation details?" If we do these tasks well as designers, we reap many benefits:

We gain our client's trust by demonstrating a clear understanding of their needs
We improve our ability to design multiple solutions for our clients
We leave a legacy of solid materials enabling our successors to understand what we did and why
We empower developers (coders) by communicating both the problem to be solved and the plan for solving it - allowing them to improve on the solution or the details as their skills and experience allow.

Sheesh! I feel like I just wrote a Joel on Software piece, although nobody in their right mind would ever mistake me for him.
4:46:51 PM [Macro error: The file "" wasn't found.]

I have been playing around with Dave's DIY Web Services (which is really cool) and Sam Ruby's Busy Developer's Guide to WSDL (also cool). Sam has put together a fantastic guide for understanding WSDL. Great job!!! I must confess that I still do not love WSDL, but at least Sam's guide makes it much easier to understand and, I hope, write for myself.
2:27:33 PM [Macro error: The file "" wasn't found.]

Our corporate proxy server will not process requests for Radio (probably because port 5335 is closed to it). That is OK for what I am doing because I generally want to access my own copy of Radio while I am developing something. In these cases I just want to bypass the proxy server. However, when I make a request over port 80 to some other machine outside our network, I do want to go through the proxy server. I have to. To better support web service developers Radio really needs a consistent means to bypass the proxy server on a call by call basis. There are a couple of easy ways to do this. I have modified several verbs to accept a flUseProxy boolean flag. A better way might be to simply modify the tcp.httpClient verb to bypass the proxy if the call is being processed on a single machine. I did that once, but lost the change during the upgrade to Radio 8.0. It worked read well. I sure would like this to be baked in to Radio.
2:27:18 PM [Macro error: The file "" wasn't found.]

I need a upstreaming driver for Microsoft's Visual SourceSafe. Suffice it to say that some of our internal sites use SourceSafe as a deployment tool. I want to publish to these sites using Radio. The simplest approach would seem to be building an upstreaming driver that will push my files into SourceSafe.

I have given this some thought and see several ways to build such a driver. Each has advantages and disadvantages. SourceSafe appears to offer three interfaces:

Visual user interface - I think this is not scriptable. Also, I really do not want the UI popping up during upstreaming operations.
COM interface - I think I once wrote another application using the COM interface to VSS; this is pretty workable, but Radio's support for COM is based on executing Javascript code. It works, but is not terribly elegant.
DOS command line - this is a very speedy interface, but will also be inelegant. Some of the driver's logic will be dependent upon the current state of SourceSafe (e.g. are we adding new files, or updating existing ones? each has different commands in VSS). That logic could end up split between Radio and a command shell script.

Another possibility has just occurred to me. The COM interface will be a lot easier to use from some Microsoft environment that provides better COM integration. I could do this in, say, C# - exposed as a web service! That is easily accessible from Radio. The only real downside is that this is not a terribly useful approach for anybody not working in a .NET environment. Then again, maybe I should focus first on solving my own problem before worrying about whether anybody else even cares.

I have other things to do first today so I will let this roll around a bit before making a decision. If you really need a VSS upstreaming driver, let me know. It will definitely have an impact on my decision.
9:14:43 AM [Macro error: The file "" wasn't found.]