Electronic Elections: Doomed

Electronic elections in the US are doomed: this pretty much settles it.

 

Our government (and I don't mean "this government" - I think it's non-partisan) appears to be completely, hopelessly addicted to technology while at the same time being pathetically inept at making choices about it.

Trailing Commas

I was reviewing some code the other day and I noticed something like this:

 

public enum Foo {

  One,

  Two,

  Three,

}

 

Note the "extra" comma after the last element. I thought to myself, "There's no way this can compile." But in fact it does, and when I stopped to think about it, I realized how nice this C# feature is. It means I can more easily reorder these elements, more easily generate source code, and in general is just one less thing to worry about. And it turns out this works for static array declarations, too, like

 

string[] foo = { "a", "b", "c", };

 

Little touches like this make life in C# pleasant.

 

I'm sure I’m not the first to notice it, but I'll bet I'm not the last, either. ;)

Dear Wharton

Dear Wharton Executive MBA Program,

 

Thank you for returning my wife.

 

Sincerely,

 

Craig

 

(Congratulations Alice!)

Irony, At Least, Is Highly Available

It's a great irony that I'm spending today working with a client trying to design a system that must be highly available, and simultaneously struggling with my email server becoming unavailable. For added contrast, the problem appears to be with the company that hosts my backup mail servers - a service I pay for in the name of high availability. :p

 

At any rate, I hope this will get sorted out soon, because at the moment our email is bouncing immediately rather than simply queuing. If you're trying to reach me (or my wife) and you got a bounce, at least now you know what's happening. You can always use my gmail address instead.

It's All Free, Y'All

Phil Haack (one of my favorite bloggers, I'm not ashamed to admit) makes an excellent point. To that end, I hereby state the following:

 

Any code that appears on this blog, or in the sections of the Pluralsight wiki, for which I own the copyright, is hereby licensed under the MIT License, unless otherwise stated.

 

I'll try to make a practice of being more explicit in the future when I post code. In the meantime, you're covered.

The Perils of WSDL First (Again)

Tim and Aaron have both pitched in on this Perils of WSDL First thread. I just want to point out that I largely agree with what they are saying. Which is good, because disagreeing with either of them on matters pertaining to web services would be enough to make someone with even my huge ego question themselves! ;)

 

They advocate use of an abstraction layer between your domain types and the XmlSerializable types you use as your web service paramaeters. This is a fantastic idea, and it's the way I write web services myself, having been bitten more than once by direct exposure of domain classes. Generally speaking, this will go a long way towards preventing the sort of problems I warn about in my original post. In many cases, it will even be sufficient, especially when coupled with Tim's idea of having the serializable types be in a separate assembly owned by someone who understands the implications of code changes on the wire protocol. And the DCS stuff that Aaron talks about looks like an excellent further step in the right direction.

 

So if I still appear skittish, it's because I know that most people don't program this way. Most people follow the path of least resistance, and will hesitate to implement writing the boring, repetitive mapping code involved in the most straightforward implementation of such an abstraction layer. Yes, I realize more sophisticated implementations are possible, but I'm talking here about people and organizations that don't necessarily recognize the long-term benefits of such a setup. As a consultant, I've seen this more than once.

 

The other thing that makes me a bit nervous is that even with an abstraction layer, you still have to be very careful not to muck with it in ways that would change the contract - a fact that both Tim and Aaron are clearly aware of. This is obvious to people who've been doing web services for a while, but for a lot of developers the angle brackets are still invisible. Basically, I'm trying to point out that web service development needs to be both first. Fragile code sucks; the more things you have to remember, the more likely you are to make a mistake.

 

Whether or not any of this means your organization needs to go whole-hog and implement IXmlSerializable really depends on the dynamics of your development process. Probably you don't need to go that far, especially given XmlElementAttribute.Order. At the end of the day, just remember that when you let the infrastructure generate your XML automatically, seemingly innocuous changes in your code can create breaking changes in your wire protocol. Remember it, and use appropriate techniques to address the risk.

Overkill? I think not

It's good to see Tim blogging again. Hopefully he'll keep it up this time (nudge, nudge, Tim). At any rate, I'll blame his lack of practice for his post "Craig urges overkill, XmlSerializer sky not falling". Either that, or he had a high temperature/blood alcohol level. :)

 

Tim writes:

 

Craig got caught in a very particular set of circumstances. First, he started with WSDL. Then he hand-wrote his serializable types. Then he followed his preferred set of rules for ordering members of those types alphabetically.

 

The implication here is that unless you're doing all those things, you won't have the issues I describe in my post. This is simply not true. The problem I describe is an issue for anyone who does not explicitly control the order of serialization of their web service-visible types. Period. While I wouldn't exactly say the sky is falling, this is definitely a Big Deal.

 

I think the reason you don't see this occurring as a problem more often in the wild is that people tend to write .NET clients for their .NET web services, and XmlSerializer doesn't care about order. Or, more generally, schema validity. But if reach is important to your web service, you should.

 

I actually talked with Tim about this on the phone, and it came out during the conversation that the problem is even worse than I first thought. I had detected the issue with return types, but the fact of the matter is that if you reorder your type members for either input or output parameters, you change the generated schema in the WSDL. And that's a breaking change (from a schema standpoint).

 

Which really was my whole point: you need to be EXCEEDINGLY careful with your types unless you implement IXmlSerializable or use XmlElementAttribute.Order. Reordering type members is just too easy for a developer to do without thinking about it, and isn't the sort of thing that's easy to catch as critical even if your team reviews all source changes.

 

As Tim points out, implementing the read side of IXmlSerializable is a royal pain most of the time (you'll note I only said "consider" using it), but XmlElementAttribute.Order is pretty easy. Of course, it's only available in .NET 2.0. :p