Ben Galbraith's Blog

September 2005 Archives

Avalon Everywhere? Cross-platform Microsoft?

Another interesting announcement here at PDC is that Microsoft is creating a subset of their cool, fancy pants UI layer (formerly code-named Avalon, now WPF) on other platforms, including the Mac! In fact, one of the demos involved showing vector graphics rendered in Safari using a Microsoft plug-in.

This subset, called WPF/E, will be powered by XAML (their XML dialect for representing the UI) and JavaScript. Sound familiar? Yes, that's right -- Microsoft also announced a Dashboard clone for Windows Vista. Interesting...

Microsoft will never port .NET to other major operating systems, but to have a subset of Avalon available on other platforms is a bit of a curveball. In fact, in light of Firefox and Safari's upcoming support of SVG and Canvas (and in the future, 3D functionality), this move makes sense; Microsoft wants to provide their own proprietary solution to cut off this new cross-platform initiative.

Also, Microsoft's Ajax framework, Atlas, will target WPF/E. The WPF/E subset of Avalon will include all of the Avalon features (vector graphics, animations, etc.) less 3D, some of their XPS features (XPS == Microsoft PDF clone), and hardware acceleration.

In a WPF/E session, someone asked if Microsoft's WPF/E plug-in will be available in Firefox; the speaker dodged the question ("We hope such support will emerge...").

My first reaction to WPF/E is frankly disappointment that they wouldn't just embrace SVG, though what I've seen of 2D XAML makes it look a while lot like SVG with different attribute names and various other differences. I wonder if XSLT will do the trick there...

Lack of many of the Avalon features in WPF/E, notably hardware acceleration, really makes it seem that the strategy is to make apps work on other platforms, but make them work poorly compared to Windows -- motivating users to switch to a Windows platform.

C# 3.0: Relational Language Operatings, Type Inference, and More

I'm here at Microsoft's Professional Developer Conference (PDC), the Big Redmond's irregularly scheduled conference where they introduce new technology to developers. It's a pretty surreal experience. I'm using the only Mac as far as the eye can see. It's kind of like JavaOne in a parallel universe.

This morning, Bill Gates and Jim Allchin got up and talked about a lot of the old stuff we've been hearing about for years now: Avalon/WPF for graphics, Indigo/WCF for services, etc. For those not following Microsoft, these are really cool technologies, but... old news.

The real interesting action happened when Anders Hejlsberg and Don Box got up and demonstrated Microsoft's LINQ project. It turns out that in a future release of .NET (3.0), Microsoft will embed relational operators into the language itself. To understand what this means, check out this C# code:

public void Linq1() {
    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

    var lowNums =
        from n in numbers
        where n < 5
        select n;

    Console.WriteLine("Numbers < 5:");
    foreach (var x in lowNums) {
        Console.WriteLine(x);
    }
}

Err, that's interesting. But hang on, it turns out you can mix and match this code with data from relational databases, all using the same operators. Check this out:

public void Linq1() {
    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

    DataContext context = ...;  // don't worry about how I get a ref to this
    Table<myobject> myTable = context.GetTable<myobject>();

    var lowMyObjects =
        from n in numbers, o in myTable
        where n < 5 and o.MyNumber == n
        select o;

    Console.WriteLine("MyObjects whose number is less than five:");
    foreach (var o in lowMyObjects) {
        Console.WriteLine(o.MyName);
    }
}

Wow. I can seamlessly combine my relational data with my object data. This is just scratching the surface of LINQ (for example, XML is also a first-class type of C# 3); check it out. They've given out pre-release bits; I'll definitely be playing with this stuff.

Oh, did you happen to notice this code snippet in one of the earlier examples?

var lowNums = ...

This is not VB code. C# 3.0 introduces type inference. That's also pretty interesting. Some folks in have been asking why Java doesn't do this for years. That is, if an IDE can figure out how to automatically write the (Cast) operator, why can't the compiler?

I remember asking one of the compiler guys at JavaOne about why they don't introduce type inference in future versions of Java; his answer: "Sounds like you want to use a dynamic language." I'm sure glad some folks understand that you don't need to throw away strong typing to avoid writing the type of a variable over and over again, unnecessarily.

Check out some of the other new features, announced today and coming to some future release sometime in the distant future.

To be clear: this is not a "Run from Java and embrace .NET" post. Rather, I'm excited to see the Java space innovate to keep up with some of these and other really intriguing new C# features. It's fun to watch the game of Java/.NET leap frog play out...

(Check out www.ajaxian.com later today for a blog on some of the Atlas/Ajax stuff that Microsoft announced today...)

(Once again, cross-posted to Married... with Children)

My Ultimate Home Office

Over the past few years, I've been doing a lot of consulting out of my home office, and the trend will continue for at least the next year. Recently I decided, "Hey, if I'm going to be spending a lot of time in here, I might as well spruce up the place a bit." Over the past few weeks, I've upgraded. Let me tell you what I've got, why I like it, and in some cases, why I still haven't found nirvana yet. Please -- comment on this entry and tell me about your setup. Well, unless you're James "Dual G5! 30" Apple LCD!" Strachan. ;-)

The Chair

I spend 10-20 hours a day at a computer. Bad habits have given me the beginning symptoms of repetitive stress injuries (RSI) in my arms, hands, and back. Comfort is real important to me. Enter the Perfect Chair:

The minute I reclined about 45 degrees, it was heaven. I work most of my day reclined that way, and, when whimsy strikes, I recline back all the way for some... brainstorming. There were some other great up-right chairs out there, but I figured, hey, if I'm at home, I may as well flaunt the freedom it affords me. Try getting your boss to approve one of these for the cube, my friend!

The Computer(s)

With the perfect chair, I've got the most important element out of the way. Next question: what computer? Since I'm lucky enough to be developing in cross-platform languages, I can choose pretty much whatever. So I went with an Apple PowerBook. Which model? The 15", of course. 12" is too cramped, and the 17" is way too large.

Ahh, nice. I love working on the Mac; the aesthetics of OS X and power of Unix are just great. Everything tends to work well together. Wonderful platform. And, wicked slow. So, when I need to actually get work done for people, I use a mutt PC that I built years ago and upgrade as it breaks (last incident was an AMD chip whose heat-sink fell off, frying itself in a few seconds). I always choose middle of the road components, and it always seems to run circles around whatever Mac laptop I'm using. Right now it's got a 2.8 GHz Pentium something-or-other, Intel motherboard, 1.5 GB RAM, nVidia 6600 AGP 8x 256 MB card (cheap but sufficient), and not much else.

The Keyboard

There are millions of folks who type on keyboards all day every day. Yet, I can't find just the right keyboard. The closest thing to perfection I've found is the old Microsoft Natural Pro keyboard. It's been discontinued for years, so I buy them on eBay when I need 'em. And I have a little stockpile.

I love that keyboard. Why? It has the only True Keyboard Layout I've found in an ergonomic style (2x3 special key block between the main keys and numeric keypad, 1-on-3 arrow key layout, slashes in the right places, and so forth); it isn't wireless, so no batteries or radio interference to worry about (I'm always by my desk anyway); it's got programmable macro keys galore; it's got a built-in USB bus; and its got pretty good OS X drivers.

Apparently, I'm not the only admirer of this sucker; they don't go cheap in on-line auctions.

The Monitor

In a stupider move, I bought a 20" Apple LCD. I got it at a discount when I joined the ADC, but even still, it was overpriced. Dell makes a 24" LCD that suspiciously matches the specs of the Apple 23" LCD and sells it for $400 less than Apple's 23". Should have done that. Nevertheless, it's a great LCD, and nice-looking too.

Once you take the recliner plunge, you've got to make accomodations for your monitor. You see, the Perfect Chair can put your feet way above the bottom of any desk I've seen, so you can't just put the chair under your desk. I put my chair parallel to my desk, and I've got an Ergotron LX monitor arm that positions the monitor over me just where I like it as I recline.

The downside of the arm is that it only tilts down 5 degrees. I need to find something that tilts down 45 degrees or more so I can position it directly above me; that should be fun.

The KVM

Two computers, one monitor -- enter the KVM (Keyboard-Video-Mouse) Switch. I've had some real bad experiences with these devices in the past, but all that's changed with my recent find: the Gefen SL Switcher.

It's a DVI/USB2 KVM siwtch that comes with a remote control! This sucker works like a champ with no signal quality problems. Can't recommend it enough.

The Software

Ugh, this is a whole separate blog entry. But let me tell you about my favorite two pieces of software. QuickSilver is *the* way to get around on a Mac. Check it out. I haven't used the Dock for ages. (Hint, QS does a lot more than app switching.)

And for code grinding, IntelliJ IDEA still can't be beat. Worth every penny.

What's Missing

I need to get an air mouse to get the Minority Report effect going, and frankly, there's not a good place for a conventional mouse in the reclining chair. I have a generic sound system (cheap Logitech surround sound system; cheap Logitech headphone/mic combo); I ought to upgrade to some THX-certified goodness and get a nice surround sound USB device for the PowerBook.

What else am I missing?

(Cross-posted on my personal blog, Married... with Children)

XML, Readers, and Streams: A Cautionary Tale

(Note: this entry is cross-posted on my personal blog site -- galbraiths.org/blog.)

If a system's glitches can be compared to fish, I want to tell you about my white whale.

A while back, I was working on a system feature that read in some XML from the filesystem, XSLT'd it into HTML, and served it up to a browser. The XML had a bunch of characters from the higher Unicode ranges (i.e., >255), and wouldn't you know, when viewed in a browser, these characters showed up as garbled data. Not "The Box"--that ugly little placeholder used when a font doesn't contain a character for a given code point--but usually one to three seemingly random characters that had nothing to do with the character that was supposed to be displayed.

Classic encoding problem.

For the uninitiated in character encodings, let me fill you in real quick. Disks store bytes, not characters. A byte is a numeric value between 0 and 255. To store characters on disks, a convention is used to map the numeric values of bytes to characters. In the early days of computing, we kept things simple and said that there could be no more than 256 different types of characters stored in files. Lately, we've taken to storing over 60,000 different types of characters. How do we represent that many values with just a byte?

Actually, that depends. An exceedingly large number of different conventions exist for mapping >256 characters to bytes. What all of these systems have in common is that multiple bytes are used to represent a single character. Two bytes can when used together represent 65,536 unique character types; with three bytes, bump that up to 16 million.

And therein lies the rub. Files don't indicate the encoding used within them. Indeed, there's no guarantee that the files store character values at all. The user must know what to expect within the file, and if its character data, they must know what encoding was used to store it.

Back to the story. I knew it was an encoding glitch; multiple characters showing up in place of one is a classic symptom (because multiple bytes represented the character, but the parser treated each byte as a unique character). I immediately assumed that the browser or the servlet (or the web framework on top of it) was to blame. I spent a lot of time educating myself on how encodings work over the web. I threw hours at the problem here and there and came up empty handed each time.

And then, whilst reading through some of the backend code, I saw this innocuous little line:

Document document = new SAXBuilder().build(new FileReader(file));

See the problem? Look again. Notice the FileReader? I'm such an idiot. Here's the deal. XML files can contain any of thousands of different Unicode characters and can use a bunch of different encodings to map those to bytes. The encoding used on a particular XML document is indicated in the prolog, such as:

<?xml version="1.1" encoding="UTF-8"?>

I don't really use XML 1.1; I just put that in to piss off Elliotte. ;-) Note the encoding. Now, back to our FileReader. Readers in Java are nice because they handle converting bytes into characters automatically. But in order to do that, they have to know what encoding was used on the bytes they are being handed. If you don't specify an encoding, a Reader will use the operating system's default encoding.

Ahhh, and there's our problem. PCs, Macs, *nix, they all use different encoding schemes by default, and they ain't UTF-8 (actually, on some *nixs it might be, I dunno). My XML files were UTF-8 encoded. So when I used a Reader to parse my XML file, the XML parser was misinterpreting many of my characters.

This is the code I should have written:

Document document = new SAXBuilder().build(new FileInputStream(file));

If you hand an XML parser bytes, which is the currency of InputStreams, the parser handles converting those bytes to characters itself, and uses the encoding in the XML prolog to configure itself for that process. If you hand it characters... it's stuck using those characters and can't affect the decoding process one whit, since it occurs a level beneath it.

It turns out this is a rather insidious bug. Because most encodings are the same in how they assign the characters mapped to byte values 0-255 (since the ASCII standard was so pervasive), and because those are by far the most common characters for most folks here in the United States, you can go a long way with character encoding bugs like this and never know any different. But the day you add a higher value character... weird things happen.

Learn from me. Spare yourself the pain of wrestling with this one yourself. Make me feel my time was well spent. Never, ever use a Reader to parse in an XML file. There's already a great system for letting the parser handle the decoding; let it.

This work is licensed under a Creative Commons License.