Thursday, April 1, 2004

I wrote this at the beginning of 2002 while channeling my energies into the Windows Forms book. I never published it, but I liked it (and I’m in writer avoidance mode as day #2 past my due date rolls by), so I thought I’d share it:

The Dark Ages, a period of five centuries beginning in 5 AD, marked a time of intellectual darkness and barbarity. A ruling feudal class kept a firm grip on their over-worked peasants in small enclaves eking out a meager living from the soil. Only lonely, isolated monks were able to record knowledge using primitive tools to painstakingly inscribing it into hand-crafted volumes, each unique and each unavailable to their fellow man. Only pilgrims and adventures, willing to endure long journeys and brave many hardships, had the chance of obtaining this secret knowledge. Finally, the Renaissance, brought on by the spread of knowledge in approachable formats using inventions like the printing press, was able to rejuvenate a weary world and bring about a period of intellectual growth and achievement that continues to this day (interrupted only briefly by the Reagan years).

The Browser Age, a period of ten years beginning in 1991, marked a time of user-interface limitations and lowest common denominators. A ruling standards body kept a firm grip on their over-worked participating members in companies large and small, eking out a meager living from IPO wind-falls. Only lonely, isolated web masters were able to record knowledge, using primitive HTML to painstakingly code it into hand-crafted pages, each unique and each unavailable to their fellow programmers. Only Perl programmers and regular expressionists, willing to parse tangled byte streams and scrape many screens, had the chance of separating the data from the presentation. Finally, .NET, brought on by the spread of the information available programmatically to rich client applications using inventions like Web Services and Windows Forms [ed: and soon, Avalon], was able to rejuvenate a weary software world and bring about a period of productivity growth and achievement that will continue until long after we retire (interrupted only briefly by the Internet Bubble burst).

Discuss

Here.

I’ve had 2600 comic books bagged and boxed in my garage since I’ve had a garage. These are comics that I collected as a kid and had always planned on turning into Benjamins. However, when doing a massive do-it-yourself Clean Sweep on my entire house, I figured it was time. But I couldn’t sell them to a local comic shop, as they can only give me a tiny fraction of their worth, so I immediately thought about eBay. And that’s why the comics have been sitting in my garage for so long. The mere thought of cataloging, assessing, photoing and posting all 2600, even in reasonable groups, was way more work than I was willing to do. And so they sat.

That is, until I was driving with a pack of MSLearning folks on our way to lunch recently in Redmond and came across a Bidadoo truck. I’d never heard of it, but they explained it as a new startup dedicated to taking your stuff, particularly your collections, and doing all of the grunt work to get it sold on eBay, including bringing in experts to help them figure out exactly what’s what. So I spent 5 hours putting making a list of what was in my 9 long comic boxes, hauled them up to their “showroom” in Redmond and now they’re getting ready to put my entire comic collection on eBay for 33% off to top. They’ve got 34 of my X-Menu comics up on eBay in 6 bundles now and they’ll be doing the rest directly.

So, in summary, buy my comics and check out Bidadoo (if for no other reason than their fun name — I’m a sucker for double meanings : ).

Here.

He said, “Do you think we should support RSS in Longhorn?”

I said, “Well, there’s that RSS Tile…”

He said, “Yeah, but shouldn’t we do more?”

I said, “Well, sure, what we should really do is blah, but we’d also need foo to make that work.”

He said, “Right. What if we did quuz to enable foo?”

I said, “Wow. That’d be cool. Can you actually make that happen?”

He said, “Yep.”

Whoa.

I was reading Paul Vick, who agrees with Carl Franklin that the "This American Life" weekly NPR radio program rocks (I'm paraphrasing : ). In addition, I really like Garrison Keillor, "Whad'Ya Know?" and a bunch of the financial programs on AM radio. However, unlike my time-shifting TV appliance, I don't have any good way to time-shift radio (the AM stuff is rife with commercials, so really needs a fast-forward feature). Anyone got something for me? Ideally, I'd be able to dump programs to an MP3 player for convenient playback.

Here. The one where Ward and I turn a spec. into a SOAP endpoint implementation compliance test.

I want all of the MS conference rooms to be like this one so that they can broadcast high quality audio and video to me at my house. I especially want a RingCam.

Thursday, March 25th, 2004

Even though Ward Cunningham and I have been living only 4 miles away from each other for some years, I really didn’t know that he lived in in the same state ’til he sold his soul hired on at Microsoft. Since then, we’ve been meeting at a local Starbucks on a regular basis to shoot the shit in a very DevelopMentor/Tektronix-like way, i.e. ramble on about whatever ’til we hit on something fun to try. In one of those meetings, we were talking about requirements for a web services API that I’m working on and he took us off on what I thought was a tangent, but turn out to be very cool.

Before Ward set me straight, I thought that Test-Driven Development (TDD) was when I built a little console app to test my APIs. I routinely do this before I write an API so that I can imagine what I wish I had to program against without being encumbered with an existing implementation. Then, I run my console app(s) afterwards for testing and regression testing, but only sporadically. I knew that NAnt let me run these tests into my build process, but since I’m a VS.NET guy and I haven’t done the NAnt/VS.NET integration work that I know I should do, I haven’t done as much with this as I knew I should be. Plus, as it was only me, it didn’t seem like such a big deal.

What makes TDD a big deal, however, is when you’ve got a team of folks. Of course, every developer is expected to check in tests for their stuff and those would be run as part of the nightly build. But that’s not the cool part. The cool part is when another developer adopts my API and puts his tests into my build process. When someone adopts an API that I build, then make certain assumptions about how it works and what side effects they can expect. TDD lets Joe R. Programmer encode his assumptions as unit test code so that when I break his assumptions during an iteration of my API, I see it as part of my compiler output.

Until I get a build error, I don’t need to know or care about Joe’s test. But when I do, I look at Joe’s unit test code and decide whether he was right. If Joe’s unit test is valid, I need to either fix my breaking change or be prepared to help everyone that uses my API to rewrite and redeploy their code. If Joe’s unit test isn’t valid, I’ve got to help Joe fix his code and prepare to help everyone else that made “invalid” use of my API to begin with. The very nicest things about TDD is that “fixing breaking changes” becomes the least painful thing to do!

This is huge. In fact, it’s so huge, that MS should provide an end point for people to submit their own unit tests against our Windows and .NET APIs so that when we make breaking changes, we can either fix them or know the proportion of folks affected by this breaking change.

Anyway, when Ward told me this, my eyes were opened and I was changed. But he was just getting warmed up. After showing me the power of formal unit tests across a team, he then went on to describe the power of putting the unit tests right into specifications themselves. For example, imagine a table in a spec laying out a series of inputs and expected outputs:

Now imagine a parser that could read through this table and execute the code being specified, checking expected output against actual output, lighting matching output green and mismatched output red:

This scheme lets designers define the spec long before it’s implemented and then check it’s progress as it’s implemented. Likewise, a spec itself can be put into the build process as another set of unit tests. Plus, the readability and maintainability of specs in this format is much improved and very much more accessible then unit test code.

But wait, there’s more. This isn’t some pipe dream. Ward has a .NET implementation of it called the FIT Framework on the web and yesterday he and I played around with it in my kitchen. Our goal was to take Ward’s .NET FIT implementation and add support to it for SOAP endpoints. We started with the ISBN Information web service that we found on xmethods.org and defined the following spec:

We specified the name of the FIT “fixture” (which is the class that implements the tests in FIT), as well as the WSDL URL, the service type and method we’d like to test, the arguments we’d like to test and the results we expected to get. We mixed in some of Christian Weyer’s Dynamic Web Services Proxy and we got this:

Notice that we’re not quite done yet, i.e. nothing is green and we’re not reaching into the retrieved XML and pulling out the Author, Publisher, etc. Still, while FIT requires a matching piece of code for every spec, we dropped a bit more metadata into the tables for the SOAP version, leveraged WSDL and have narrowed the project to a single piece of generic code for any WSDL-described SOAP endpoint (so long as Christian’s code can parse it).

Our plan is to finish up the extensions to FIT for SOAP and to put it into practice on the SOAP API that I’m currently designing and even to push it into our build process if I can. Further, I’d like to build another FIT fixture that, instead of executing the tests, generates sample code to demonstrate example usage and expected output (including expected errors). Rest assured, when we get it working well enough for public consumption, Ward and I will publish the SOAP extensions for your enjoyment.

But don’t wait for that! You can do TDD with custom actions in VS.NET 2003 and with the FIT Framework today!

Discuss

Tonights Portland Nerd Dinner was a barn-burner. Not only did we have the typical geek banter and laughter, but we spend some time on the question I posed the other day about what should replace character stream-based programming.

The problem is that all of the hand-crafting of solutions doesn’t scale. The answer was posed by a fellow nerd who, who pointed out that we’ve already got a model for self-organizing, self-evolving, self-maintaining systems: biology. God didn’t hand code humans and zebras and platypi — he defined a class and instance encoding method (DNA) and an environment to serve as the runtime (Earth) and let us interact with and improve ourselves and our environment over time to solve the problem. What’s the problem? What species survives best on this planet. So far, we’re the winners, but we’ll see what happens at the next ice age or when the next asteroid hits.

.NET and Longhorn have provided us a big step forward in terms of hand-crafting computer-based solutions to our problems, but only self-organizing, self-evolving, self-repairing systems can really scale. I know that IBM has done some work in this area with their automonic computing, but my personal favorite work on this topic is Genetic Programming III by John Koza. Anyone for a Genetic Algorithm Runtime (GAR)?