# Thursday, 18 March 2004

Thanks to all of you who showed up yesterday in Portland to make it a great show.  I had a lot of fun presenting, and got lots of very interesting questions.  And I was gratified to hear that there were more people in Smart Client track (that's me) than on the web side.  I got some very good questions from someone who was possibly the yougest attendee I've run across.  He looked like he was maybe 14-15.  Good to get them started young. :-) 

I thought the demos and the content for the Smart Client sessions were quite good (and all the demos worked).  Kudos to Vertigo.  Someone asked me why business weren't using the IssueVision sample application to do real IT call tracking.  I suggested he check the license before recommending that anyone take that approach. ;-)  It was nice to hear though.  Not something people often say about sample applications.

All in all, a good time was had by all. 

Thursday, 18 March 2004 09:01:12 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 17 March 2004

I found this site via Omar Shahine, and I just couldn't help myself.  There are so many more places to visit.

 


create your own personalized map of the USA or write about it on the open travel guide

By comparison this one looks less impressive :-)

 


create your own visited country map or write about it on the open travel guide
Wednesday, 17 March 2004 13:46:02 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 15 March 2004

I found myself in the position this week of having to rewrite a bunch of XML parsing code that was all written using the DOM (that I didn't write).  It's not that I really have anything against the DOM model, but it seemed like overkill, since this particular code actually was organized into subroutines, each of which would take a string and load it into another XmlDocument instance.  And in each case, all that happened with the DOM was a single XPath query using selectSingleNode.  Pretty much a performance disaster. 

What I found interesting is that when I changed it all to use XPathDocument/XPathNavigators instead, the performance didn't seem much better.  Granted, I didn't do a very scientific investigation.  I'm running NUnit tests inside VS.NET using the NUnit-Addin, and the before and after NUnit tests completed in around the same time.

I'm not suggesting I'm sorry I changed the code, since it's both aesthetically more pleasing (at least to me) and has the potential for better performance over larger documents (and I'm assuming a lot less memory overhead).  I was just surprised that it wasn't faster.  I guess I really should profile both cases and see what's really going on performance wise.  Maybe I'll get around to it eventually ;-)

In a few places where the XPath wasn't really important I changed it to an XmlTextReader instead, and was gratified that the NUnit tests completed in about a quarter of the time that the DOM was taking.  Every little bit counts.

XML
Monday, 15 March 2004 09:57:09 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Saturday, 13 March 2004

I just survived my very first Taekwondo tournament!  Yea me!

Better than that, I actually won one of my sparring matches, which I hadn't really expected to do, and the guy I lost to was WAY better than me and totally deserved it. 

I call that a good day.  Now on the the USTU state trials in May. :-)

Saturday, 13 March 2004 19:52:47 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 10 March 2004
I'm a big fan of alternative building methods (check out the Monolithic Dome Institute for one of my favorites) so this idea strikes me as pretty cool [via Gizmodo].  It's basically taking the 3-D printer concept to a larger scale, so instead of printing machine parts out of resin (which is also pretty dang cool) you "print" your house from blueprints using concrete or adobe.  What a great idea. 
Wednesday, 10 March 2004 11:29:45 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
Wow

And I thought I was a dork...

This guy proposed to his girlfriend by building a "bridal-themed" case mod.  With a little bride and groom and everything.  I feel pretty socially ept by comparison.

Wednesday, 10 March 2004 09:08:32 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 04 March 2004

I love Eric Lippert's series on "Cargo Cult Programming".  I've often seen it as a problem, but never had such a catchy label before. 

I've long been a proponent of the idea that you can't be a successful architect without understanding how the underlying system (all the parts of it) work.  For example, I may be architecting a system that relies on storing data in SQL server.  I mostly likely won't be the one to do the actual SQL Server implementation, since I'm not the best qualified.  There are plenty of people who understand TSQL, indexing, and suchlike DBA stuff way better than I do, but I need to understand how SQL server works at a deep enough level that I can make informed decisions about architecture. 

I would encourage anyone working as a ".NET Architect" to read books like .NET IL Assembler, or CIL Programming.  You may never write a single line of CIL, but you can't really understand how to make good decisions about .NET architecture unless you understand what's really happening under the covers.  In case you are interested, I would recommend CIL programming over the other.  It's much easier to read, and more practically oriented, although there are some interesting details about things like .EXE headers and such in .NET IL Assembler.

To be a good architect, you don't have to know every last detail about how everything works.  In fact, IMHO, you shouldn't and can't know all the details of how things work.  That's for other people (domain experts) to know.  I would argue that an architect should avoid getting caught up in domain details, since it tends to lead you to think that everything is an exception.  Many programmers I've known in the past who really know the intimate details down to the last speck for some particular domain (an industry standard, or a piece of hardware, etc) tend to think of all the ways in which their area of expertise contains exceptions.  "Two credit reporting agencies send addresses this way, but the third sends them differently".  "The monitor always returns a valid value for this reading, except when it's too cold in which case it's -1". 

Architects who gets too involved in those kinds of details may miss the opportunity to uplevel their thinking and change their underlying model of the system.  If everything looks like an exception to a rule, then more than likely the rules are wrong.  But if you know all the details, it's easy to see the exceptions instead of trying to find new rules that work.

It's hard to find the middle way.  If you don't know enough about how things work, you'll make poor choices.  If you know too much, you may miss the big picture.  And, of course, the reality is that these days the systems we architect are often so complex that you just can't afford the space in your brain to hold all the details about the whole thing. 

It's also tempting to want to understand all the details because of how "neat" it would be to write that part of the system.  That's a trap I find myself falling into on big projects.  The reality is, though, that I just won't have time to write the whole thing (no matter how neat it is), and I have to let go and trust that someone else will understand the details. 

Hmmmm.  That ended up somewhere different than where I started, but I hope that makes sense.  Find the middle way.  Understand enough about how the system works to make good decisions. 

Thursday, 04 March 2004 09:27:48 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 03 March 2004

I'm in the midst of doing some integration with a third party company, and their XML is driving me loony.  The worst part is, it's not something you can quite put your finger on.  Their XML is, in fact, well formed.  It might be valid, except that the DTDs they provided us with aren't internally valid, at least according to XMLSpy

I guess the biggest thing that bugs me is that their XML is, like, so 1997.  They're still using DTDs.  Every single element in the entire InfoSet is defined as a global element and then referenced.  Not a single attribute appears anywhere, so everything is element-normalized to an unhealthy extreme.  It just seems like XML that dates from a time when our ancestors didn't quite grasp the XML concept.  Anybody remember DSSSL?  It's like that.  Only well formed. :-)

And did I mention namespaces?  No?  Not a namespace declaration to be found anywhere. 

It's not "wrong" XML, it's just "wrong headed" XML.  Or maybe I'm just an effete, schema-writing elitist.  It's a tough call. 

This is what's holding back the dream of XML biz-to-biz integration.  Lack of progress in understanding how to use XML, not XML itself. 

XML
Wednesday, 03 March 2004 15:28:39 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

Scott's been extolling the virtues of Oddpost for a while now, and deriding the quality of the (admittedly) lame web client my ISP provides for checking my home email at work, so I finally tried it out this morning.  I've got to admit, it's pretty freakin' cool.  They have a very nice interface, it's easy to use, supports multiple external mail servers, etc.  I'll try if for a while longer, but I just may end up subscribing.  I think it's probably worth the (very reasonable) $30 a year. 

Now if they only supported Firefox...  It's become my browser of choice, and it's a pain to have to launch IE to use Oddpost, but c'est le vie I guess.  I have to keep IE around for SharePoint anyway.  SharePoint looks OK in Firefox, but I don't think they've got SSPI authentication working yet, so I have to sign in on every page, which gets old in a really big hurry.

Update: after playing with the client some more, I'm also impressed to see software written by people with a sense of humor :-)

Wednesday, 03 March 2004 09:42:29 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 02 March 2004
Rico Mariani has posted yet another great performance improvement story, and a fabulous illustration of the fact that the best way to solve performance problems is to really know your numbers.
Tuesday, 02 March 2004 11:54:49 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

There's been a lot of ruminating around here lately on the subject of CS degrees.  Who has one, who doesn't, and does it really matter.  I've done a fair amount of thinking on the subject, and thought I'd just go ahead and let it out.

I don't have a CS degree.  I had a very nice time earning my (basically useless) BA in East Asian Studies.  Seemed like a good idea at the time.  But then the bottom dropped out of the Japanese economy, and nobody really cared about doing business with them any more.  There went that consulting job I was hoping for.  The bottom line remains, however, that knowing what I know now I wouldn't have done things any differently. 

At the time I wasn't in touch with my inner geek.  Liked working with computers and all, but who wants to do that for a living?  Some random circumstances and the needs of my bank account landed me in a QA monkey job at Central Point Software (remember PC Tools?), and the rest is history.  I've taken a lot of professional development courses, and a few at local community colleges, but not much "formal" education in computer science.  And yet, I've managed to (I like to think) have a pretty successful career as a software developer / architect (so far). 

I think the reality is that getting a CS degree doesn't make you a good problem solver.  I've known and interviewed plenty of people with CS degrees who I wouldn't hire to write code.  I've known plenty of very talented coders who don't have CS degrees.  So on the whole, my personal experience has led me to believe that for the vast majority of jobs, it really doesn't matter.

I'm not saying there aren't jobs in which it does matter.  I'd be hard pressed to write an operating system, or embedded software, or graphics internals.  But how many people have those jobs?  Not that many, in the greater scope of things. 

I've thought about going back to school in pursuit of an MSCS or some such, but over the last 6-7 years, multiple people have told me that it really wouldn't make much difference at this point.  And I have to hold down a full time job and raise two kids, etc, so taking the time and money to go to grad school hasn't been a big priority. 

And yet, I still run into people who are hung up on the idea that you can't possibly be good at your job unless you have that piece of paper hanging somewhere.

All right, enough of my obviously biased opinion.  But if any of you out there happen to be in high school wondering what to do with yourselves, pursue a liberal arts degree.  If you learn how to think about things, what you choose to think about is just a detail of syntax.

Tuesday, 02 March 2004 11:04:32 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [3]  | 
# Monday, 01 March 2004

I'm currently listening to Tenacious D's eponymous first album, and I've got to say every time I hear it I'm amazed. 

Not only is it some of the funniest stuff I've ever heard (Tribute being my personal favorite) but it's actually pretty good musically too.  If you like that sort of thing that is.  I guess I do. 

Speaking of good music, I listened to the new Johnny Cash box set, Unearthed.  I guess I'd never fully appreciated Johnny Cash.  What a great collection of music.  Some of the modern rock songs he covers are truly fabulous, and there are some great duets.  I love his cover of Marley's Redemption Song with Joe Strummer, and his cover of Nine Inch Nails Hurt is possibly one of the saddest and yet most beautiful songs I think I've ever encountered. 

I'm getting all this through Rhapsody, but I might just have to shell out for Unearthed (which just happens to be available on iTunes).  So much media, so little time.

Monday, 01 March 2004 09:42:16 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  |