Gordon Weakliem's Weblog

Moving Day

Mon, 13 Oct 2003 04:08:59 GMT

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.

Intuit and the lost art of personal finance programs

Thu, 09 Oct 2003 22:57:01 GMT

Ted Leung relates his frustration with Intuit. Intuit lost me long before the DRM thing, by acting like a bunch of used car salesmen. These days, you install Quicken and get 10 icons on your desktop and spend weeks turning off the screens asking if you want to give more money to Intuit. I recently found a Python based checkbook program, as well as CBB, written in Perl. My demands aren't much more than something that will let me balance my checkbook and keep track of my mortgage, and maybe enable tracking transfers between accounts (a big maybe, I think I could live without). As it is, I've been running with the same copy of Quicken since 1996, but recently decided to download my Visa statement in Quicken format. Unfortunately, my version can't read it correctly, and judging from the state of the imported data, it looks like Intuit was still using 2 digit years back in 1996; I suppose a Y2K bug gives people a reason to upgrade. Looking at the reviews on Amazon, the latest Quicken sounds like a disaster, and MS Money doesn't score too much better. Come on, personal finance programs have been widely available for what, twenty years? I don't think I'm being unfair by saying that an electronic checkbook is pretty much a solved problem. I'm not shelling out $30 - $40 for a 3 star (or less) checkbook program, at least not until I've explored the alternatives.

Python in DrScheme

Sat, 04 Oct 2003 00:27:55 GMT

Matthias Felleisen announced that the latest CVS for DrScheme allows you to write Python in DrScheme. Nifty. I've noticed that DrScheme has a Java view as well - with Python support, it supports all the languages that I write in Eclipse except Ruby.

A quick primer on SOAP

Fri, 03 Oct 2003 21:39:32 GMT

Les Orchard recounts Sam Ruby's quick primer on SOAP. It's pretty aggravating that SOAP toolkits never take Sam's approach. A number of approaches that I see that I don't like:

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.

Interestingly, we have a customer who's essentially doing Sam's approach. His implementation language is MUMPS. To each their own.

A new Lisp Book

Fri, 03 Oct 2003 21:24:22 GMT

lemonodor pointed at drafts of Peter Siebel's new book Lisp book, to be published by Apress. The other day, I added an RSS feed in NewsGator, hoping that I'll get a notification when Peter's book gets published. You could get the same thing in Atom format, as well. I also created a feed to let me know when new Lisp books are released (RSS 0.91).

Moving Away From XSLT

Fri, 03 Oct 2003 19:53:29 GMT

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.

Never Fear Sir, For I Have a Cunning Plan...

Fri, 26 Sep 2003 19:14:23 GMT

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.

Radio seems to have a general problem with escaping characters and creating well-formed XML in general. I'm about ready to pull the plug on this and try something else. Cornerhost and Thoughtlocker seem to be reliable and offer most of what I want (LAMP, on a reasonable budget), though Thoughtlocker seems to give a bit more for the money and also provides Ruby.

Then there's this other wild idea. I've been working with Scheme and SSAX lately and I'm really intrigued. PLT is a nice, if idiosyncratic, IDE, and SISC could be made to run in a Java Servlet. One other possibility would be to use SSAX to generate xHTML fragments and then use something like Bloxsom on the server side to manage the static files.

Struct or Class?

Wed, 24 Sep 2003 22:20:56 GMT

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.

Remember This

Fri, 19 Sep 2003 04:47:13 GMT

Remember this the next time someone compares software construction to building a house: "Well, what I've learned from my first large construction project is that this is hogwash. The building industry doesn't know how to do anything on schedule or on budget, either."

Balancing Developers and Testers

Fri, 19 Sep 2003 04:47:11 GMT

Joshua Allen has an interesting post on the changing balance between development and testing resources, at least at Microsoft. While the general claim that the advent of managed code has made developers so much more productive that the testers are now overwhelmed is pretty significant, the really interesting quote is in the third paragraph: "there is always the possibility that the ever-increasing test expenditures will not coincide with a reduction in the number or severity of high-profile security and quality incidents". To me, that suggests that the skill set for testers is changing. Now I understand that it's typical for MS to hire more development oriented types as testers, but in every company I've worked for, testers tend not to have significant programming experience and are on the whole less technical than the programmers. So testers tend to concentrace on UI and HCI types of tasks and not so much on security analysis. I think that testing for security would require a technical and likely a programming background, so I would expect that companies that are concerned about security would not simply reduce programming headcount, but would end up moving programming resources from development to testing. In the end, assuming that companies manage their people efficiently, I expect that the increased programmer productivity would be a wash, rather than an opportunity to reduce headcount.

Building airplanes

Mon, 15 Sep 2003 23:44:24 GMT

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.