Contract First? Code First? Both First.

The recent debate (here, here, and here, amongst others) might lead you to believe there are two ways to design a web service: code-first and contract-first. A surface reading of the debate seems to indicate that you either write a bunch of classes and rely on the vendor to generate the XML (code-first) or write all your WSDL/XSD by hand (contract-first). This is utter crap.

Just like anything else, it all comes down to Splosky's Law. Roughly paraphrased, it reads, “There is no free lunch.“ You don't get to ignore the wire format, and you don't get to ignore the tools. Instead, you have to remember things like, “CLR value types don't work very well in the face of missing elements, but Java works differently.“ You, lucky coder, have to remember that you're writing a system in which the parts might look something like this:

Java <-> Axis <-> XML <-> HTTP <-> XML <-> System.Xml.Serialization <-> ASP.NET <-> C#

And that every layer has its own oddities and idiosyncrasies. If you can do that by writing a pile of classes, great. But you simply won't be able to guarantee success unless you know how those classes turn into XML. You might get lucky, but that's pretty much the same thing as saying, “Well, there was a threading bug, but I ran it again and it didn't happen, so it must not be a problem.“ Similarly, you can't just hurl an XSD at the world and expect that everyone will write code to consume the corresponding XML directly off the wire - they're going to use vendor toolkits for the simple economic reason that it's too expensive not to.

Note that I'm not putting words into the mouths of any of the participants in this debate. Many of them make the same points, although not, I think, in the same “camp neutral“ vein. My point is that you can claim to be either a “contract-first” or “code-first” person and still succeed. Which pretty much makes the distinction (and therefore that aspect of the debate) pointless.

No, call yourself whatever you want, but you still get to learn the stack from end-to-end. Programmers hate this because they spend their life building abstractions, and this flies right in the face of that. Vendors hate it to admit it because it means they can't sell toolkits that “take care of everything for you.” (Not that they don't try.) But at the end of the day, the universe doesn't care that we don't like it - it's still the case that abstractions leak, and knowledge is the only insurance.

Making iTunes Work with MSN Messenger's &amp;quot;Now Playing&amp;quot; Feature

On a recommendation from Brad Wilson, I've switched from using WMP to iTunes. I'm not sure I'm going to stick with it, but so far I like it. But one problem that was bugging me was how to get the “Now Playing” feature of MSN Messenger 7.0 working. I had it working for a little while, but then it stopped and I couldn't get it back.

Well, I've got it working now. After a little Googling, I found the answer here. Here's the important bit:

In MSN Messenger go to Tools / Options / General and check "Open Messenger main window when Messenger starts."

This rates as one of the more bizarre fixes I've seen, but so far it's working perfectly.

In the spirit of this post, here are my five most recently played songs. Clearly, I've got my whole library on “shuffle“. :)

1. 
   
   The Separated Man: I'm in a Cage/I Am the Man/The Man's Gone [Reprise]/Some - Neal Morse - One


2. 
   
   Concerto Per Mandolino, Archi E Cembalo- In C Major RV - Antonio Vivaldi


3. 
   
   Piggy - Nine Inch Nails - The Downward Spiral


4. 
   
   Home - Dream Theater - Dream Theater Graspop Festival 2002


5. 
   
   Turn on Tune In - Threshold - Hypothetical

This Blog Now Requires CAPTCHA

I've had some fairly serious problems with comment spam on this blog - literally hundreds of bogus comments on some days. I've been trying to keep on top of it, but it's a pain. Now, thanks to the efforts of Keith Brown, a CAPTCHA feature has been implemented. Hopefully this doesn't discourage anyone from commenting. Given that it only requires you to type in four numbers, I suspect it won't.

Please contact me if you have any problems with this feature.

Visual Source Safe and Visual Studio 2005?

Looking at this chart, it's unclear to me if I'm going to have to cough up for a VSS license in addition to dropping money on VS2005. Of course, I've never been too clear on VSS licensing in the first place. (And frankly, I'd pay quite a bit not to have to use it, particularly given the number of alternatives that are both superior and free). But I know there are a lot of midsize shops out there that use VSS, and I'll bet they're going to be asking themselves the same questions.

Periodic Slowness in ASP.NET Apps

This one came up on the FlexWiki mailing list the other day. I should have known it, but I missed it, and it's worth spreading around.

A user complained that their FlexWiki install would periodically respond very slowly. The wiki was under very light load, so it didn't seem like a traffic problem. I was initially a bit confused, because the user reported that they hadn't changed the <processModel> element. Changing <processModel> to recycle the ASP.NET worker process periodically would have explained the problem, but the default is not to do that.

At that point, Michael Teper pointed out what I should have remembered: under IIS6, <processModel> is ignored in favor of the IIS6 metabase settings. If you go into the Internet Services Manager and pull up properties for an application pool, you'll see right there that by default, IIS will recycle the worker process every 29 hours (yes, 29), and after 20 minutes of inactivity. So on a lightly-loaded server, you're going to see a lot of recycling, and the consequent periodic delays. If you're supporting an internal web server that doesn't get hit that often, changing this value might be a good idea.

How to Tell You're a Network Nerd

Got this one in my email today. I thought it was too funny not to share:

---

Dear Dr. Internet:

I am afraid that I'm becoming a network nerd. How can I tell for sure?

Sincerely,

Geek-or-not

---

Dear Geek-or-not:

How many syllables do you think there are in the word "coax?"

Dr. Internet

---

MIT Students Generate Gibberish

OK, we've all been to a conference talk or two that sounded like the author had been smoking the thesaurus. But this beats them all: some MIT students wrote a program that randomly generated a meaningless conference talk paper. Then they submitted it. And it was accepted.

[Update: forgot to credit Shawn Van Ness for pointing this one out on the WinTechOffTopic Mailing List.]

Fixing GotDotNet?

It looks like James Newkirk (of NUnit fame) is switching jobs. He's going to be helping to develop the next generation of GotDotNet.

I say, fantastic! First of all, you all know that I think GotDotNet sucks. I like SourceForge much better, but not so much that I would mind seeing someone do something even better.

Mr. Newkirk, if you're listening, here are my suggestions:

1. Support automation. GDN currently has no good ways to automatically check in/out. As an NUnit guy, I can imagine this is high on your list. :)
   
2. Switch to a edit/merge/commit source control model. The SourceSafe lock/edit/checkin model has no place on teams where people sit more than three feet from each other. I'm pretty sure I know what you're using on the back end for source control, and it's awesome. Expose it.
   
3. If you absolutely must support lock/edit/checkin (to pander to all those frightened by the word “merge“), for the love of all that is technical, make it something I can turn off.

That would be an excellent start. If you can additionally

• Provide an interface for automating releases.
  
• Provide built-in continuous integration with excellent integration points.
  
• Provide well-integrated bug and feature tracking.

Then you'll be a leg up on SourceForge, and I might consider switching.

One piece of advice: avoid the Microsoft trap of thinking you have to write the whole thing from scratch. That's one of the reasons GDN sucks now. There are tons of good bits out there that already do a lot of what we need (e.g. CruiseControl.NET). Note: I will be highly suprised if this actually happens. Microsoft culture is pretty bad on this count - I think you get sprayed with NIH spores when you walk through the door.

In any event, I wish you the best of luck. The worst-case scenario for me here is that SourceForge steals some of your ideas and makes my experience even better. So I win either way. :)

Another Smart Guy Hits the AOP Crack Pipe

Ted Neward recently blogged about Tim's XSLTO project. If I might be so bold as to summarize Ted's argument:

XSLTO looks like AOP. Tim thinks XSLTO is good. Therefore, Tim thinks AOP is good.

This is so full of holes you could strain your pasta through it. It's a classic case of overgeneralization, and in and of itself that's enough to render his argument moot. However, I'd like to examine it in slightly more detail.

Ted's basic argument is that since XSLTO uses declarative attributes to drive execution of code, and since AOP is based around more or less the same thing, that the two are equivalent. I disagree: XSLTO is a proper subset of what AOP advocates. It is a specific, specialized utilization of declarative programming. In this case, it's essentially a translation of XSLT into the C# realm, giving you the ability to process XML documents via recursive descent.  

Ted says:

And the richer and more flexible your pointcut/query system, obviously the more powerful your AOP system. This is why simple interception, such as the CORBA interceptor, .NET/COM+ context-bound attribute interceptor or Java dynamic proxy, is not a rich AOP system in the slightest--although powerful, it uses only one sort of joint point, and that in itself inherently limits your abilities. Imagine if OOP only allowed just one base class or interface; how useful would OOP be?

Still pretty damn useful, actually. I don't miss multiple inheritance in C#, despite it being a mainstay of C++. Adding more constructs to the language adds complexity, and that complexity adds cognitive overhead that can make the tool less useful in many situations. We have this conversation on the FlexWiki mailing lists all the time: people are constantly proposing extensions to the wiki syntax that bring it closer and closer to doing everything HTML can do. Of course, at some point you cross the line where you have to wonder why you should bother with having a wiki language at all? It's like Spider Man taught us: with great power comes great responsibility.

(Side note: Multiple interface implementation is probably a borderline case - I suspect we could get by without it, but since it adds less complexity than multiple inheritance, the increased cognitive load is probably worth the extra capabilities. That is not always generally true. Figuring out when it is and when it isn't is what designing good abstractions is all about, and it's really, really hard.)

Continuing. Quoting Ted:

As to the oft-quoted "killing blow" regarding AOP systems, that being that aspects cannot be ordered or stateful, it's interesting to note that people refuse to make similar accusations about XSLT, yet it (a) fundamentally presents much the same kind of programming model as an AOP-based system would, and (b) has similar problems with ordering and state, yet nobody's calling for XSLT to die....

Ted, if you want to compare AOP to XSLT, be my guest. Programming in XSLT every day of my life for everything I do would be enough to make me want to switch to a career in marketing. Just like XSLTO and AOP, XSLT is a specialized tool useful for a few very narrow problems. And just like XSLTO and AOP, it should be viewed as - although perhaps not a last resort - something you only pull out when you have a specific need, not a general-purpose tool.

At the end of the day, I guess what Ted and I disagree on is the extent to which AOP concepts are useful. I say, “very little, but not zero”, and he takes a view that is presumably much broader than that. I view XSLTO as a useful replacement for some of what XSLT does. And I view XSLT as a useful replacement for some of what the .NET XML APIs do. But most of the time I'm going to stick with my favorite API, XmlSerializer, and stay the hell away from frameworks that drive execution¹ via declarative means. I take the same attitude towards (other) AOP frameworks: I'll use them when I've exhausted other options, and not before.

1. Yes, I realize XmlSerializer is declarative. But it's a declarative serialization engine, not a declarative execution engine. (That is, I don't need to debug into it except when I have problems, which is when it sucks the worst. But that just makes my point.) I have found this to be a very significant difference in practice. And again, a concept that is useful only in a narrow context.