bugfox blog

via Raymond Chen, David Vronay describes the travails of producing a version of the classic Minesweeper game for Windows Vista, subject to the restriction that it mustn’t offend anybody. I’m not sure whether this is good customer service or political correctness run amok.

David M. Kean lists the rules that Microsoft considers mandatory for internal development.

The XML xs:dateTime format specifies that the date and time must be passed in ISO 8601 format. Also you will probably want to pass it in a time zone-independed way. The easiest way to do this is to covert the date to UTC (a.k.a. Greenwich Mean Time or “Zulu”). This can be done as follows:

public const string ISO_UTC_FORMAT = "yyyy-MM-ddTHH:mm:ss.sZ";
DateTime date;
XmlWriter w;
String s = date.ToUniversalTime().ToString(ISO_UTC_FORMAT);
w.WriteString(s);

The other thing to be careful about is never to use XmlReader.ReadElementStringAsDateTime() to read this data. At least in Framework 3.0 (an probably earlier) it will IGNORE THE TIME ZONE INDICATOR. Instead use

XmlReader r;
DateTime dt = DateTime.Parse(r.ReadElementString());

The standard DateTime.Parse() handles the ISO format correctly.

Elliotte Rusty Harold has drawn at least one nasty comment for his remarks about checked vs. unchecked exceptions in Java: Voting for Checked Exceptions.

In fact he is exactly right. Unchecked exceptions are for errors in your code that should be found during testing. Checked exceptions are for unpredictable errors caused by the program’s environment. The trouble is that many Java programmers (probably most Java programmers) don’t really understand the distinction, leading to confusion, bad code and general resentment of the concept.

I blame Sun for this. They never did a good job of explaining the distinction, and even gave the exceptions misleading names. “RuntimeException” for unchecked exceptions is exactly backwards. It suggests that even some of the designers of the Java libraries didn’t understand the concept.

C# From a Java Developer’s Perspective a handy point-by-point comparison of the differences between the two languages by Dare Obasanjo.

Useful tips from John Manoogian III: (The Only) Ten Things To Know About CSS. But why does the page look so ugly in IE?

David Megginson offers a funny but insightful summary of the most important ideas in REST: The Quick Pitch:

The elevator pitch

With REST, every piece of information has its own URL.

If you just do that and nothing else, you’ve got 90%+ of REST’s benefits right off the bat. You can cache, bookmark, index, and link your information into a giant, well, web. It works you’re reading this, after all, aren’t you? Betcha got here by following a link somewhere, not by parsing a WSDL to find what ports and services were available.

Sanjiva Weerawarana, one of the primary people responsible for the SOAP and WS-* specifications, defends them in an interview with InfoQ’s Stefan Tilkov:

InfoQ: Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths

Tilkov is a fairly hostile questioner, obviously arguing the REST viewpoint. Weerawarana provides calm and rational answers, though I don’t necessarily agree with them. Here are what I think his key points are, along with my responses.
(more…)

I know I’ve been dissing SOAP and WS-* quite a bit lately, but I can’t let this pass unnoticed.

If Richard Monson-Haefel of all people can’t easily use one of the leading toolkits to create a simple client for some of the most popular web services, how likely is it that the average programmer will be able to do a decent job? Keep in mind that the main selling point of these frameworks is that they are supposed to make it simple to use web services.

I think it’s time for the tool vendors to admit that this whole approach is a mistake. The idea of creating distributed applications by making RPC calls across the network, using code generators to hide all the details of network communications, has been around for over ten years. It sounds appealing at first, but we have had time to see how well it works in practice:

• Fragile, hard-to-maintain applications.
• That generally don’t scale well.
• And usually won’t interoperate with other vendor’s frameworks.

Tim Bray responds to Elliotte Rusty Harold’s negative comments in this post:

Hey Elliotte, I guess making friends and influencing people is for losers, right? The proof of the pudding, obviously, is in the eating, but the fact that this discussion is happening has to be a good thing.

Marc Hadley responds with some clarifications of what they are trying to do, and some sample code to show what they have in mind.

HTTP is the target of this API, we went back and forth a bit on the name and in the end decided to use RESTful in there to highlight that it will focus on RESTful use of HTTP. It doesn’t mean we plan to develop an abstract REST API with a binding to HTTP.

The sample doesn’t look to bad; at least it looks better than the existing APIs. However I see some issues that I hope will be addressed:

• The sample seems to assume that the message contents will be passed as strings. This would be fine for short messages but would probably be very inefficient for long messages.
• MIME attachements would also need to be supported.

ERH asks

why is this being proposed for Java Standard Edition at all? The proposal seems to depend on JAX-WS and the Java Servlet API, neither of which is included in the Java 6 Standard Edition. Will these packages have to be added to Java SE just to support this?

That’s a good point. Obviously there needs to be two packages:

1. A client-side API that belongs in Java SE
2. A server-side API that should be part of Jave EE or installable separately

Does that require two separate JSRs?