# Tuesday, November 09, 2004

The Hollywood Foreign Press Association has announced that it won't consider Michael Moore's Fahrenheit 9/11 for any Golden Globe awards because they don't give awards for "documentaries". 

Apparently they haven't actually watched the film.  (I finally saw it last week.)  Whether or not you agree with Moore, you can hardly call F 9/11 a "documentary".  It's clearly political theater, and anyone who claims it's a documentary is missing the point.  A lot of criticism that came out against the film centered on the fact that it was biased and didn't give both sides equal time.  Of course it was biased.  It's theater.  Documentarians don't pull stunts like Moore does.  Political satirists do. 

Anyway, agree with Moore or not, I think it's a bit disingenuous of the HFPA to claim that they won't consider it because it's a "documentary".

Tuesday, November 09, 2004 3:32:13 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  | 
# Monday, November 08, 2004

Our CTO, Chris, recently turned me on to Ruby.  I've been playing around with it a bit over the last few weeks, and I've got so say I'm pretty impressed.  I really appreciate that it was designed, as they say, according to the “Principal of Least Surprise”.  Which means that it basically works the way you would think. 

Ruby has a lot in common with Smalltalk, in that “everything is an object” kinda way, but since Ruby's syntax seems more (to me at least) like Python or Boo, it seems more natural than Smalltalk.  Sure, you don't get the wizzy browser, but that's pretty much OK.  When you apply the idea that everything is an object, and you're just sending them messages to ask them (please) to do what you want, you get some amazingly flexible code.  Sure, it's a bit squishy, and for code I was going to put into production I still like compile time type safety, but for scripting or quick tasks, Ruby seems like a very productive way to go.

Possibly more impressive was the fact that the Ruby installer for Windows set up everything exactly the way I would have thought (”least surprise” again) including adding the ruby interpreter into the path (kudos) and setting up the right file extension associations so that everything “just worked”.  Very nice.

The reason Chris actually brought it to my attention was to point me at Rails, which is a very impressive MVC framework for writing web applications in Ruby.  Because Ruby is so squishily late-bound, it can do some really amazing things with database accessors.  Check out the “ActiveRecord” in Rails for some really neat DAL ideas. 

I'm assuming that that same flexibility makes for some pretty groovy Web Services clients, but I haven't had a chance to check any out yet.  Anyone have any experience with SOAP and Ruby?

Monday, November 08, 2004 6:48:14 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, November 02, 2004
Just in case you somehow missed the fact that it's election day, Go Vote!  If you don't vote now, you don't get to bitch later. :-)
Tuesday, November 02, 2004 9:43:40 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, October 29, 2004

The last working day before Halloween is upon us (as evidenced by the giant Sponge Bob sitting over in QA) and Drew brings us a poem of distrubed systems horrors.  A great read!

Friday, October 29, 2004 9:44:02 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, October 27, 2004

So, one the things we do in CERT (Community Emergency Response Team) training is simulated disaster exercises.  One of the things you need for simulated disasters is simulated victims.  What you want from a good simulated victim is something that looks realistic, and preferably really gross.  If you get used to dealing with simulated grossness, the theory is it will be easier to deal with actually grossness when it shows up. 

Enter "moulage".  (I'd never heard that word either.)

"Moulage" is the art of making people up to look like they have horrible disfiguring wounds that will be noticed by people in medical training, and dealt with accordingly.  Last night I went to a moulage class put on for our local CERT team, and it was really a lot of fun, in a gross, messy kind of way.  I hope to have pictures later. 

We spent over an hour looking at a combination of moulaged volunteers and actual accident victims to get a feel for what we were trying to achieve.  Yuck.  People can get hurt in really messy ways.  Then we set about making each other look gross, which was much more fun. :-)

My favorite ones were the burns.  It turns out to be really easy to make some really nasty and convincing looking third degree burns (using common household items).  I had a harder time with the "impaled objects" and compound fractures.  Mostly because I was trying to work on myself.  It's way easier to get a chicken bone to stick out of someone else's arm than your own.  And it takes a lot more artistic skill than the burns to get the colors right.  Ah, well.  Now I have an excuse to dress my kids up as accident victims for Halloween.  I need to practice.

Wednesday, October 27, 2004 3:16:34 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, October 26, 2004

As most of you probably have already heard, according to Dare, we won't be getting XQuery with Whidbey. 

LAME!

One of the reasons given for this decision is that customers want something that is compliant with W3 standards.  OK, that's true.  I would disagree that people will only use something that is compliant with a full recommendation.  Back in the day when MS first started putting out XML tools (early MSXML, SOAP Toolkit, etc.) many of those tools were built around working drafts, and we still managed to use them to get real work done.  I would argue that even if the XQuery spec were to change substantively between now and it's full recommendation-hood (which I doubt) there's plenty of opportunity to get real work done with XQuery starting right now. 

The counter argument is that people don't want to make changes to their code when the real spec ships.  Guess what!  There have been breaking changes introduced in each new revision of the .NET framework.  People have to change their code all the time.  I had to unwind a huge number of problems do to the changes in remoting security between .NET 1.0 and 1.1.  Somehow we manage.  The excuse of "well, you still have XSLT" just doesn't cut it IMHO.  XSLT is a much more difficult programming model than XQuery, and most people to this day don't get how the declarative model in XSLT is supposed to work.  XPath 1.0 is very limiting, which is why there's an XPath 2/XSLT 2 (which also are not going to be supported in Whidbey!). 

I have to wonder if performance issues aren't closer to the truth of why it's not shipping.  Writing an engine that can do arbitrary XQuery against arbitrary documents certainly isn't an easy thing to do.  Think SQL.  SQL Server is a non-trivial implementation, and there's a reason for it.  I'm guessing that the reality of trying to make XQuery perform the way people would expect is a pretty daunting task. 

Either way, I think it's a drag that we won't get XQuery support, recommendation or no.

XML
Tuesday, October 26, 2004 11:00:54 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

Steve Maine is in the midst of the perennial debate between SOAP and REST, and I feel compelled to add my two cents...

At the XML DevCon last week I noticed that it continues to be fashionable to bash the existing Web Services standards as being too complex and unwieldy (which in several notable cases is true, but it's what we have to work with at this point) but that doesn't change the fact that they solve real problems.  I've always had a sneaking suspicion that people heavily into REST as a concept favored it mostly out of laziness, since it is undeniably a much simpler model than the SOAP/WS-* stack.  On the other hand, it fails to solve a bunch of real problems that SOAP/WS-* does.  WS-Addressing is a good example. 

I spent two years developing an application that involved hardware devices attached to large power transformers and industrial battery systems that needed to communicate back to a central data collection system.  We used SOAP to solve that particular problem, since it was easy to get the data where it needed to go, and we could use WS-Security to provide a high level of data encryption to our customers.  (Utility companies like that.)  However, we had one customer who would only allow us to get data from the monitors on their transformers through a store-and-forward mechanism, whereby the monitors would dump their data to a server inside their firewall, and we could pick up the data via FTP.  This is a great place for WS-Addressing, since all the addressing information staid inside the SOAP document, and it didn't matter if we stored it out to disk for a bit.  There is no way that REST could have solved this particular problem.  Or, at least, no way without coming up with some truly bizarre architecture that would never be anything but gross.

REST is great for solving very simple application scenarios, but that doesn't make it a replacement for SOAP.  I agree that many of the WS-* standards are getting a bit out of hand, but I also agree with Don Box's assessment (in his "WS-Why?" talk last week) that given the constraints, WS-Addressing and WS-Security are the simplest solutions that solve the problem.  There's a reason why these are non-trivial specs.  They solve non-trivial problems.

So rather than focusing on REST vs. SOAP, it's more interesting and appropriate to look at the application scenarios and talk about which is the simplest solution that addresses all the requirements.  I don't think they need to be mutually exclusive.

Tuesday, October 26, 2004 10:01:27 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Friday, October 22, 2004

Update:  the link to the article seems to be broken.  Fie!

The Marin Independent Journal published an article about some of the fascinating medical work my Dad and his wife do in San Francisco.  Pretty cool stuff.  The article mentions the trip we took to Disneyland this summer.  Once again, the Internet knows everything. :-)

Friday, October 22, 2004 12:29:07 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Thursday, October 21, 2004
Wow, Rory drew my head.  I've arrived. :-)
Work | XML
Thursday, October 21, 2004 9:35:02 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, October 20, 2004

Sam Ruby is talking about problems with textual data out on the web, or more specifically in the context of RSS, having to do with bad assumptions about character encoding.  As someone who once did a lot of work in localization, it's a subject near and dear to my heart. 

I'm always amazed that still to this day people don't get that there are such a thing as character encoding. 

Sam points out that an upper case A and the Greek Alpha show up in most fonts as the same glyph.  However, they are different code points in Unicode. 

He's moving this idea up the stack to show why there are so many conflicts between HTML/XML/RSS/etc.  The rules for character encoding are different in all those systems and are enforced differently by different tools, which is what causes so many RSS feeds to be badly formed. 

He started the presentation talking about how XML is an "attractive nuisance" with regard to the encoding issue, in that it leads people down the primrose path to thinking all their encoding issues are solved just because XML is supposed to take care of encoding. 

All in all, the issues Sam is talking about are pretty obscure, and appeal mostly to XML wonks, but that doesn't make them any less valid.  The reality is we've all learned to deal with it most of the time, just like we're used to IE fixing up our bad HTML tables.

XML
Wednesday, October 20, 2004 3:51:23 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |