You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Thursday, Mar 25, 2004, 8:23 PM in .NET
Taking Advantage of Enterprise Features in Indigo
In this piece, Karsten digs into some of the advanced features of Indigo, building the code to start from scratch on the client and server, then adding the code to add state management, reliability to the messages and asynchronous messaging.
Thursday, Mar 25, 2004, 7:29 PM
What the Heck Is It With Today?
Here. First, I'm swamped in work. Then, I'm swamped in news. Finally, I'm swamped in sales, with the book at it's all-time low on Amazon.
Thursday, Mar 25, 2004, 4:59 PM in Tools
Web Site Dedicated to Extending VS.NET
I swear I only stopped reading blogs for a coupla days, but interesting news has just surged! For example, I just found out that MSDN has an entire web site dedicated to extending VS.NET. This includes the legendary VSIP and a set of extensions that lets you build VSIP packages in managed code. Very cool.
[via Visual ActiveKent Sharkey .NET SE 3.11]
Thursday, Mar 25, 2004, 4:23 PM in .NET
I've Seen Monad and I Am Pleased
The most concise description of what I love most about Monad, the next-gen Windows command line, comes from Jeffrey Snover, a Microsoft Architect, in a Peter Coffee article:
"We keep the idea of 'A pipe to B pipe to C,' but we pass .NET objects instead of structured text. We can pass ADO, other kinds of objects, and we can create reflection-based utilities."
Just the idea of not having to deal with ambiguous from standard input or reparse the data at every stage of the shell pipeline makes me giddy with anticipation.
Thursday, Mar 25, 2004, 4:14 PM in Tools
VS.NET Whidbey Has a Command Shell Window Built It
It's well hidden, but Jason Olson points out that VS.NET Whidbey finally has a command shell built right in. Now if only it changed folders with my solution and support completion via the tab key, support F7 and F8...
Thursday, Mar 25, 2004, 3:18 PM in .NET
XAML is VB's "With" on Steroids
Marc's post made me connect VB's With statement for performing multiple operations on a single variable with XAML's terse, but powerful, syntax.
Thursday, Mar 25, 2004, 3:12 PM in .NET
XAML is Not Your Father's HTML
Jason Olson talks about dock, absolute and relative positioning in Avalon and shows XAML mark-up examples that make his points nicely.
Thursday, Mar 25, 2004, 3:07 PM in .NET
Don Answers: Does Indigo Need IIS?
Don Box talks about how Indigo services are hosted and how that interacts with IIS (or not, as the case may be).
Thursday, Mar 25, 2004, 3:06 PM in .NET
Adam Kinney on Avalon Property Triggers
Adam has a nice, concise sample of property triggers in Avalon, which are a XAML way to change the properties of an object based on an action, e.g. implementing rollover. He also shows a small example of using property triggers with animations to build pleasing transitions.
Thursday, Mar 25, 2004, 2:48 PM in The Spout
Checking Spec. Compliance at Build Time
Here. The one where Ward and I turn a spec. into a SOAP endpoint implementation compliance test.
Thursday, Mar 25, 2004, 11:19 AM in The Spout
What Every Conference Room Should Be Like
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, Mar 25, 2004, 12:00 AM in The Spout
Checking Spec. Compliance at Build Time
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!
Wednesday, Mar 24, 2004, 7:13 PM in Tools
Very Cool Web Service Testing Tool from Mindreef
I knew Mindreef had cool testing tools, but I just found one today on their web site that I ended up using all afternoon. You feed it a WSDL URL and it generates a form, allowing you to see the SOAP request and response packet in several formats include raw XML, to pseudo-code, pretty-printed XML and tree. It's much more flexible then the built in one that ASP.NET provides and the price is right.
Wednesday, Mar 24, 2004, 10:42 AM
It's All Down Hill From Here : )
Here.
Rory says:
"I mean, here was this guy who managed to make .NET Code Access Security look like fun. It'd be easier to pull a three-headed monkey in a tutu singing barbershop choir out of your ass, but he still accomplished it. Even my girlfriend who didn't know diddly about coding walked away making thoughtful noises to herself. To this day, she sleeps in a blue oversized Chris Sells t-shirt. How many other coders out there have silk-screened images of themselves draped over the nubile naked bodies of women as hot as my little tart of a girlfriend? Not many, my friends. Not many at all."
I'm met Rory's "tart of a girlfriend" and there's really nothing more I need to consider accomplishing. : )
Wednesday, Mar 24, 2004, 10:06 AM in .NET
Tom Barnaby on Preparing for Indigo
Tom Barnaby has some tips for preparing today for Indigo tomorrow.