# Monday, April 19, 2004

My wife and I went to see Hellboy last night.  Humph.  I was disappointed.  The hightlights were the art direction, which was very consistent and retro-cool, and Ron Perlman was a fabulous choice for Hellboy.

However, there was little to no character development in a script that really called for some.  Hellboy is supposed to be a much more tragic figure than he comes across as because of the lack of characterization.  And John Hurt's professor was totally one-dimensional. 

A pretty film, and worth a viewing, but I won't rush right out after the DVD when it comes out.

Monday, April 19, 2004 10:17:50 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Saturday, April 17, 2004

I just saw the new Omnimax film that's playing at OMSI here in Portland.  What an amazing film.  I've seen a bunch of Omnimax films, and I think this was one of the more compelling.  It's composed of profiles of four people who go fast for a living: a sprinter, a mountain bike racer, a race car driver, and a race car designer.  All set to Mozart, and hosted by Tim Allen.  Very cool.  Lots of Omnimax-optimized footage of going fast.  Some of the coolest stuff was footage of the mountain bike racer, Marla Streb, who's been clocked at 67 mph, down a mountain on a bike.  That's pretty amazing. 

If it's playing anywhere near you, it's worth checking out.

Saturday, April 17, 2004 5:40:43 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, April 16, 2004

OK, I realize this is apropos of nothing, but I'm most of the way through The Clash's Clash On Broadway, and I've got to say it just doesn't get any better than this.   

What a great, groundbreaking band they were. 

Friday, April 16, 2004 4:09:14 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

Now this is just plain annoying...

As I've mentioned before, I'm doing some ongoing work with code generation from XmlSchema files.  Developers mark up XmlSchema documents with some extra attributes in our namespace, and that influences how the code gets generated.  Think of it as xsd.exe, only this works.  :-)

So today a new problem was brought to my attention.  I read in schema files using the .NET XmlSchema classes.  OK, that works well.  For any element in the schema, you can ask its XmlSchemaDatatype what the corresponding .NET value type would be.  E.g. if you ask an element of type "xs:int", you get back System.Int32.  "xs:dateTime" maps to System.DateTime, etc.

When you want to serialize .NET objects using the XmlSerializer, you can add extra custom attributes to influence the behavior of the serializer.  So, if you have a property that returns a DateTime, but the schema type is "date" you need some help, since there's no underlying .NET Date type. 

public class MyClass
 public DateTime SomeDate

The XmlElementAttribute tells the serializer to enforce the rules corresponding to the schema datatype "date" and not "dateTime".  Groovy so far.

However, the XmlSerializer only supports certain schema types for certain CLR types.  Makes sense, as this

 public Int32 SomeDate

doesn't really make any intuitive sense. 

So now for the catch.  The CLR types that the schema reading classes (System.Xml.Schema) map to schema types don't in all cases match the CLR types that the XmlSerializer maps to schema types.  The schema reader says that "xs:integer" maps to System.Decimal.  OK, that's consistent with the XmlSchema part 2 spec.  Unfortunately, the XmlSerializer says that "xs:integer" must map to a System.String.  So does "xs:gYear", and several others. 

The end result is that I can't rely on the XmlSchemaDatatype class to tell me what type to make the resulting property in my generated code.  Arrrrrggggghhhhh!!!!!!!

The two solutions are basically

  • tell people not to use integer, gYear, etc. (possibly problematic)
  • have my code embody the differences in type mapping between XmlSchema and XmlSerializer (lame)

I haven't delved, but I can only assume that xsd.exe uses the latter of the two. 

Work | XML
Friday, April 16, 2004 3:39:42 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

[Update] The OPTOPlay completely rocks.  Driverless install, works right out of the box.  Absolutely no background noise, no interference from the disk, and it's got a little pre-amp, so the headphones sound great.  Woohoo!

[Update] I just ordered one of these.  We'll see if that makes a difference.

How hard can it be to put a little shielding on either a hard drive or a soundcard?  I've had 2-3 systems in a row (at work, so I can't complain too much) that don't have any decent shielding inside, so I hear the hard drive spinning over my headphones, which is annoying as all get-out.  On my current IBM box, it's not intrusive enough to keep me from listening, but on my last Compaq laptop, it totally was.  The headphones were completely useless due to all the interference from the drive.  In a laptop, OK, I'm willing to cut them some slack although it's still pretty lame.  On a desktop system it shouldn't be so hard. 

I wonder if they just assume that anyone serious enough to bother to use headphones will shell out for a soundcard and not use the crappy stuff on the motherboard.  I suppose you could also make the argument that a business PC doesn't need decent sound, but I (and others I know) spend large parts of the day wearing headphones while coding to cut down the din of living in cube-land.  And Rhapsody is just so dang handy.

It's enough to make a guy buy an external sound widget like the Extigy.  That would put things a good distance from any unshielded drives.

Friday, April 16, 2004 8:59:09 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, April 12, 2004

I just got asked a question at work that reminded me how many people still don't quite "get" XML.  And I still find it surprising.  We've now had a good 6-7 years of XML being fairly present, and 3-4 years of it being pretty ubiquitous.  And yet...

Once upon a time I wrote (and taught) a class on XML for a variety of customers, and when I think about the experience now, I think the hardest thing to get across to people is how to visualize the InfoSet.  It's not flat.  XML looks flat when you see it on a page (not flat in an ISAM way, there is hierarchy, but flat in a 2D kind of way), but the InfoSet isn't.  As soon as you introduce things like namespaces and ID/IDREFS, the InfoSet itself is really this big n-dimensional think that's hard to get your head around.  If you look at the XPath spec, it should provide a big clue.  It talks about navigating InfoSets in terms of axes.  That's exactly what they are.  Namespaces are a separate axis.  They come right out of the screen at your face.  It's not flat

And that's not even counting what happens when schema gets into the picture.  The shape of a "Post Schema Validation InfoSet" may have very little to do with that the XML looks like on the page.  That's why Binary XML shouldn't be scary to anyone.  It's just another way of serializing the InfoSet, not the XML.  Think about the thing that the XML becomes being serialized in a different manner, not the XML itself.  "Binary XML" in and of itself sounds pretty silly, since the whole point is that XML is text.  But "Binary Serialized PSVI" doesn't sound so silly, and may have some distinct advantages. 

OK, in rereading that I realize it may make sense to nobody but me, but given the self-indulgent nature of blogging I don't really care.  :-)  If I can help just one person see the InfoSet and not the flat XML, I'll sleep that much better at night.

Monday, April 12, 2004 3:54:49 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

If you have any interest in builds or code maintenance (like I do) check out vil.  It's a code metrics tool that works directly on .NET assemblies.  The interesting thing (IMHO) about that approach is that when it gives metrics for lines of code, complexity, etc. that's all with regard to IL, and not the C# or VB.NET or whatever that you wrote in the first place. 

That makes sense when you consider all the stuff that get's compiled out, although particularly with things like lines of code it may be misleading.  Particularly in C#, where keywords can expand out to quite a bit of code.  Most of the other metrics still make sense with regard to IL, and of course even lines of code is useful when used for comparison rather than absolutist purposes. 

Monday, April 12, 2004 3:20:40 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

Roy's released the latest version of The Regulator, which continues to build upon what has become my favorite regex tool.  You can now generate .NET code for your regex straight from the tool, and for those of us who have to work with someone else's regular expressions, there's an analyzer that explains the regex in English.  Pretty cool stuff. 

Thanks Roy.

Monday, April 12, 2004 2:53:00 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, April 09, 2004

I wasn't sure I'd pull that one out...  it's been a while.  I actually just had a grammar nazi episode with my son last night (who didn't appreciate it, being 8).

Grammar God!
You are a GRAMMAR GOD!

If your mission in life is not already to
preserve the English tongue, it should be.
Congratulations and thank you!

How grammatically sound are you?
brought to you by Quizilla

[Via Steve [Via Stuart]]

Friday, April 09, 2004 11:07:44 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, April 07, 2004

I'm really wanting to fold some kind of code coverage tool into my automated build process.  I'm using CruiseControl.NET to do continuous integration builds, which run NUnit tests, FxCop, build docs, etc, all through the wonders of NAnt.  The problem comes when trying to decide which code coverage tool to run.  For more info, see a presentation I did for a user group meeting a while back.

There seem to be two different projects, both called NCover that provide code coverage for .NET projects.  One of them is at GotDotNet, and it uses the profiling API to get coverage data from a running assembly.  Pretty cool, but I haven't been able to get it to work reliably with NUnit tests.  I think that NUnit doesn't allow enough idle time for the NCover output to get flushed to disk before the process goes away.  Drag.  However, I see that a new version was release yesterday, so I'll have to try it out and see how that goes.

The other NCover follows a more traditional source code intrumentation approach.  You build your project with it, which injects coverage hooks into your source, then you run your tests and out come coverage reports.  Cool.  And somehow it just feels more reliable to me than depending on the (slightly witchy) profiler interface.  On the other hand, it requires a lot more setup and is much more intrusive.  But it seems to work. 

Does anyone have any experience with one or the other?  Or any opinions?

Builds | Work
Wednesday, April 07, 2004 9:17:44 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [5]  |