Busted

The wise Scott Hanselman and Richard Blewett both noted that my recent post about SoapParameterStyle.Bare was apparently at odds with Tim's post about the same thing. Well, they're right. The reason? My post was - to use the euphemistic engineering term for “lame“ - sub-optimal. But allow me to explain, hopefully clearing up any web service confusion that may have arisen.

Tim and I had had an interesting conversation one afternoon while I was at his place, in which he explained to me the pattern he describes in his post...of which SoapParameterStyle.Bare is an part, but only a part. More important is combining SoapParameterStyle.Bare with the style of using a single input and single output parameter - without this you don't realize all the benefits that Tim outlines in his excellent blog entry.

Anyway, when I posted, I didn't want to tell the whole story, because I was trying to goad Tim into blogging it, and didn't want to steal his punchline. But by only explaining half, the post wound up missing the point. I've updated my old post to point to Tim's stuff in the interest of community service. :)

Nice Explanation of Direct3D Frame Hierarchies

I get occasional emails from people that go something like, “Hey, I like your Direct3D Tutorial. When are you going to write more?“

D'oh! It's been months since I've written a new one, but between work at two clients, FlexWiki, moving the weblog, and all the other stuff going on, I just haven't had the time (although writing more is still on my list).

Luckily, others are not quite so lax. For instance, Joakim Karlsson has just posted a nice explanation of how to create and use a basic frame hierarchy. He's got another article on fullscreen device recovery, too, so here's hoping that he finds time to write more Direct3D stuff soon.

dasblog2dottext Released

Peter and I did some work this weekend and got dasblog2dottext released! This is a very handy tool that Peter wrote; it imports all of your dasBlog content into a .Text instance, which is what made it easy for me to move my weblog here. Peter even wrote a little redirector that forwards all comment and permalink pages over to the appropriate entry on the new site.

What's funny is that I'm the one that wrote the BlogXToDasBlogImporter that's part of the dasBlog workspace. Hopefully I won't need to migrate to anything else for quite some time.

Anyway, the project is up on SourceForge...enjoy!

My New Home

If you're reading this, you're aware that I've moved CraigBlog to its new home here at Pluralsight. But why did I move? And why so suddenly?

Let me address the last point first: the move was only sudden from a public point of view. I wanted to throw the switch and have everything flip over to the new site as quickly as possible because I wanted to take all my posts - and the comments on those posts - with me. The longer the lag between the new site going live and the old one getting redirected over, the more information I was going to lose (or have to move manually). So I've actually been talking to the Pluralsight guys about this for weeks, and have spent a fair number of evenings and lunch hours getting it set up.

But back to "why". It's really simple, actually: because I think the Pluralsight guys are an absolutely top-notch group of dudes (as well as being good friends), and hanging out with them in virtuality seemed like it would be fun. They've got an exciting new company going and history, if nothing else, would indicate that they're going to be producing some excellent stuff. When they asked me if I'd be interested in coming over, I figured that if I can help them out by bringing some more traffic their way, I was happy to do it.

Oh, and as a consultant who lives by his reputation, it doesn't hurt me at all to hang my blog shingle up next to names like Aaron Skonnard, Don Box, Fritz Onion, Keith Brown, Mike Woodring, and Tim Ewald. :)

I'd like to thank Fritz and Keith in particular for handling their side the transition of CraigBlog - I've got a fair amount of content, and I had some requirements that they had to run around a bit to meet. I'd also like to think Peter Provost, who wrote the excellent dasBlog2dotText conversion tool, which is what made it possible for me to port all my content in a few hours rather than a few months. He and I are going to be releasing the tool on SourceForge this weekend - I'll be sure to let you know here (at my comfy new home on the web) when it's ready.

System.Decimal Appears Horribly Broken

Run this code:

using System;

public class App
{
  public static void Main()
  {
    Decimal a = 57675350989891243676868034224m;
    ShowModulus(a, 7);
    Console.WriteLine();
    ShowModulus(a, 8);
  }

  public static void ShowModulus(Decimal a, int m)
  {
    for (int i = 0; i < m; ++i)
    {
      a++;
      Console.WriteLine("{0} % {1} = {2}", a, m, a % m);
    }
  }
}

And you'll get this output:

57675350989891243676868034225 % 7 = -2
57675350989891243676868034226 % 7 = -1
57675350989891243676868034227 % 7 = 0
57675350989891243676868034228 % 7 = 1
57675350989891243676868034229 % 7 = 2
57675350989891243676868034230 % 7 = 3
57675350989891243676868034231 % 7 = -3

57675350989891243676868034225 % 8 = 1
57675350989891243676868034226 % 8 = 2
57675350989891243676868034227 % 8 = 3
57675350989891243676868034228 % 8 = 4
57675350989891243676868034229 % 8 = 5
57675350989891243676868034230 % 8 = 6
57675350989891243676868034231 % 8 = 7
57675350989891243676868034232 % 8 = 0

I may not know much, but I know that something is wrong there: the way negative numbers are showing up is inconsistent. Frankly, I don't think they should be there at all, but if they are, you'd expect similar patterns between mod 7 and mod 8. Try it with numbers other than 57675350989891243676868034225, and for moduluses (moduli?) other than 7 and 8, too. It breaks for those as well.

This appears to be a bug in the Decimal.Modulus routine - caveat emptor. Oh, and it's still broken in the Whidbey version I'm running (40607). I tried to submit the bug over on the new MSDN Product Feedback Center, but I get an error every time I try to submit. D'oh!

Frankly, this would scare the crap out of me if I were writing financial or scientific software that relied on System.Decimal. In my case the apparent workaround is easy (add the modulus to the result if the result is less than zero), but my confidence in the algorithm is pretty low.

I Like It Bare

Update: Be sure you read Tim Ewald's post about Doc/Literal/Bare - as I explain elsewhere, this post tells only half the story, and in fact mostly misses the point.

My, my, it has been quiet around here for the last week, hasn't it? My excuse is that I was in New Hampshire all week, working heads down on the MSDN rewrite with Tim Ewald and some other friends. My other excuse (always have a backup ready) is that I'm working on some big changes to this blog...but more about that soon enough.

Tim is always a font of entertaining but useless jokes, and enlightening and useful XML knowledge. One thing he pointed out to me this week was SoapDocumentMethodAttribute, in particular when specified with SoapParameterStyle.Bare.

Allow me to explain. Compare the XML produced by the following two functionally equivalent SOAP endpoints:

[WebMethod]
public int Add(int x, int y) { return x + y; }

and

[WebMethod]
[SoapDocumentMethod(ParameterStyle=SoapParameterStyle.Bare)]
public int Add(int x, int y) { return x + y; }

Here are the request/response messages for the first variation:

---

POST /play/bare.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://tempuri.org/Add"

        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 
   
      int
      int
   
 

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 
   
      int
   
 

---

and here they are for the second variation:

---

POST /play/bare.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://tempuri.org/Add"

http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 
    http://tempuri.org/">int>
    http://tempuri.org/">int>
 

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 
    http://tempuri.org/">int>
 

---

Notice the big difference? With the second variation, the wrapper element that corresponds to the method name has been removed. Which is nice, because it's superfluous - the method is already specified by the SOAPAction header. This is particularly nice in the response message where that extra level of indirection looks a little silly.

To me, this just seems like nicer XML; more like how I would do it if I were just using XmlWriter and raw sockets.

If Only Tomorrow Were Today

Oh, I so want this. [via Steve Rodgers]