This will very likely be is the last post at this weblog.  After some delay, all the parts are in place, and I have a new weblog at www.eighty-twenty.net/blog, and I expect that all my future posting will take place there.  I'm attempting to redirect the RSS feed, but I'm actually not sure how many aggregators support this, and AFAIK, there's no way to get Userland's servers to do a proper 301, so we'll see.

Update: It looks like none of the 3 aggregators I tried (NewsGator, RssBandit, and BottomFeeder) understand the XML-level RSS redirect, so you'll probably need to update your feed manually.  I'll do a redirect later if I find out a way to do it more portably.

• Hiding the transport under some sort of "service" object. SOAP4R did this, last time I looked. It makes it a pain to configure the transport - I couldn't figure out how to put HTTP credentials. Why not just have the client create the transport and have the SOAP envelope serialize itself?
• Hiding the raw XML. SOAP should require nothing more than an XML parser (and a transport library, usually HTTP). That even beats XML-RPC, where you have to have a library that knows the serialization rules.
• Not supporting Document/Literal. Doc/Literal is so much easier than RPC/Encoded, yet everyone does RPC/Encoded. Allegro recently released a Lisp SOAP client, but it doesn't do Doc/Literal (yet). If I were writing a SOAP library, I'd forget about RPC/Encoded.

Martin Fowler is moving away from XSLT. I agree completely with all of his criticisms. For a great example, look at the abomination I had to go through to get ISO-8601 dates into an Atom feed. The assumption is that the release date for a book can serve as both the issued and modified time. I do have decent date information coming from Amazon, but it's in a format like "3 October, 2003", and the day of the month is omitted for unreleased items. It's not too hard to parse this: if the first characters are numeric, they're the day, otherwise default to some number (either the 1st or last of the month, I'm not worried about accuracy). Alternately, you can split the string on spaces: if you get 3 fields, the first is the day. The second part is a simple table lookup: associate numeric strings to month names. The year is pretty easy, it's the part following the comma in the string; for the rest, just make up a time (book release dates aren't accurate past a day anyway). Anyway, all of this is hard in XSLT; in Python or Ruby string handling is easy and dictionary lookup is easy. The advantage of XSLT is the same as Java's in the sphere of general programming languages: it runs almost everywhere. XSLT's disadvantage is that it's a transformation language, and a transformation on XML Elements and Attributes, principally; XSLT falls apart when your transformation needs to work on text nodes. There are XSLT extensions that would improve some of this, but I'm dependent on Amazon in this case for my processor, and in any case, the use of extensions defeats the platform independence XSLT should give you. If you're going to do that, you might as well use a general purpose language.

That said, Martin's approach looks great. He borrows XSLT's rules based approach to handling nodes, but retains the processing power of Ruby. I believe that XSLT's real power is in the XPath matching and querying coupled with the rules based approach. It's just a matter of coming up with the framework; you could have the same in Ruby as well. I've been working with SXML lately, and it's based on the same theory: once you create a framework for pattern matching and querying, you have XSLT, but without the limitations.

I've posted 8 times in the past month, and 2 of my posts have contained links with a query string. Radio seems to have developed a charming habit of trashing the equal sign in a query string.

• This entry contained a garbage character in the query string, which which got replaced with some other garbage when I tried to edit it over email. At least this garbage is valid XML.
• The previous post that had a query string got trashed, and then Radio escaped my markup when I tried to fix it (that could have been my fault, trying to fix the post hastily). That post is staying the way it is, I've tried fixing it 3 times now.

I've been reviewing a draft of a book on C#, and while reading the author's discussion of struct, I disagreed with the author's criteria for determining whether to declare a class as a class or a struct, which came down to a decision over whether you'll ever want to subclass the type and whether you'll be passing the type as a parameter or returning them from a method.  For the first point, I'm of the opinion that it's really hard to guess whether a class will ever be subclassed, and in any case, I'm not a big fan of sealed classes, so class would win in this case.  Second, I understand the point that you don’t want to kill the stack by passing around large structs, so maybe you don't want to declare a struct with 100 fields, but lots of structs get passed around the FCL – System.Drawing.Point and System.Drawing.Rectangle, are used extensively in System.Windows.Forms, for instance.  Maybe the choice should be class by default, and to use struct as an optimization; at least I’m pretty sure that’s how the FCL authors made the distinction. I don’t know how I’d determine that optimization was necessary; analyze the heap activity maybe? Isn't this a case of trying to outguess the GC?   In any case, you can get around the copying problem for method parameters by declaring them as ref.  I think that most programmers will encounter Value Types by creating their own enums; in 2.5 years of .NET programming, can't remember ever declaring a struct.

Over at je apostrophe, there's a quote from one of the early conferences on software engineering: "We build systems like the Wright brothers built airplanes-build the whole thing, push it off the cliff, let it crash, and start over again." I've been reading To Conquer the Air: The Wright Brothers and the Great Race for Flight. The book (at least the early chapters) is basically a contrast between the efforts of Samuel Langley at the Smithsonian Instutition and the Wright Brothers. Langley's method was in fact much like what the quote describes: build the whole plane, launch it, and pick up the pieces. The Wrights took a much different approach - these days, we might call it an "Agile" process. One really salient point was that the Wrights insisted on designing an ideal wing by doing actual, frequent experiments with a glider and a human pilot, while Langley concentrated on producing a powered craft but flying it unmanned. Langley's approach became mired in the complexity of balancing weight vs. power - you make the engine more powerful, it adds weight, so you have to add lift, which changes the flying characteristics of the plane. Langley's approach also required that the design decisions be made up front, and frequently he would get only one test flight from a design, because the aircraft was destroyed on landing. The Wrights invented a wind tunnel so they could observe the performance of small prototype wings and make an educated choice of the best performing wing, while all their contemporaries were operating off of untested assertions. The Wrights dealt with the complexity of creating an aircraft that would be controllable in the air, and then dealt with the problem of adding an engine to a craft that was known to fly well. Meanwhile, Langley fixated on the problem of powering the airplane, but never was able to produce one that had good flying characteristics. Langley assembled a large team of engineers and workmen and was constantly running out of money and seeking new sources of funding, while the Wrights worked alone and were mostly self-funded. I'm really enjoying this book because I see a lessons in how the Wrights approached an unexplored problem domain. Boeing and Airbus don't build airplanes like the Wrights, because they have a hundred years of experience to draw from, and because their aims are markedly different. The Wrights just wanted to make something fly, they weren't building a 777. It's also very interesting that the Wrights didn't patent their invention, partly because they believed that the first person to fly wouldn't be the ones to become rich off of the achievement. It seems that they were correct: aviation got its first practical use during World War I and commercial aviation didn't get started until the 1920s and 30s, after their patent would have expired, assuming that they patented it in 1903.