Would you like some frost with that?

One of the reasons I love living in Seattle is the weather. It is not that I love rain. It is that I love not melting in the summer and not freezing n the winter. I move to Seattle from Rochester, NY (where I attended the University of Rochester), which has some of the worst weather of anywhere I have lived. Seattle may not be as mild as SoCal, but I'm actually happier for that. I just prefer not to have to scrape ice off my car every day for months unending; not to have to shovel snow or drive on snowy/ice roads. I have lost one car to ice roads (someone else lost control and ran into my parked car.) and prefer not to make a habit of it.

Why that random rant? Because I had to scrape frost off my car this morning. It really was just a heavy frost. Still, having to spend a few minutes waiting for the defrost to melt it all reminded me of my days of yore, and how I really do like living in Seattle.

One last digression. Seattle has a reputation for rain. I had read, some years ago, that New York City got more annual rainfall than Seattle. So I looked it up. According to GoNorthwest.Com Seattle averages 36" of rain annually. According to EssentialBigApple.Com NYC averages 47.2" annually. (Thank you Google) Not only does NYC get more rainfall, it gets over 31% more!

So where does Seattle's reputation for rain come from? The clouds. As in, Seattle has that reputation because it is by far the cloudiest city I have ever lived in. Unlike the New England coast, where I grew up, the clouds commandeer the sky, and tend to just stay there. All day. Or sometimes all month. Also, while Seattle doesn't get as much total rainfall, it sure takes it's time getting what rainfall it does get. Rainy days in Seattle rarely include the heavy rains I was used to in the North-East. Seattle just gets lots of light precipitation. That lasts for days, if not weeks. A few years ago Seattle has something like 90 days straight of some sort of precipitation. Possibly the most depressing winter ever.

But today is bright and cheerful so far. Good way to close an eventful year.

how to be creative

I think I found my new bible: Hugh Macleod's How to be creative.

XML is like Perl

While visiting my parents for the Holidays, I caught up with some old college friends. One of the guys who was a close friend and had a huge impact on me is one of the principals at a small startup. They build a network appliance and he and I were chatting over geek details. He was telling me how they use XML. Basically, as part of the services that their box provides, it allows you to do some simple aggregation and data integration. One of the more common mechanisms they leverage for this is simple XML web services. SOAP or REST, although it sounds like they tend to use SOAP. They could do some really cool stuff. It was interseting to chat about why they like XML. I can easily understand why they would use XML. If you use SOAP, you are forced to use XML. Why people like XML is far more interesting to me.

Part of my job is to help design/evolve the APIs we expose for using XML. I love talking with programmers who use XML just as part of getting their primary job done. It helps remind me what is important to our customers. As an implementer it is too easy to get caught up in the details, the really ugly parts of the spec, or the most interesting aspects to implement. It is very easy to forget that most users never touch any of that. They use the 20% of the spec that lets them get their job done. (note: This is why I dislike the XML-Namespaces spec. It is a sneaky, nasty surprise lurking around the corner to trip up the casual XML user.)

My friend uses XPath, SOAP, and a few other XML-isms because it really does make his life easier. XML isn't the most efficient way to get the job done, but every platform and it's mutant offspring have some support for XML. For pushing 'data' around a network, XML is a supremely useful glue. Just like people use VB, Javascript, Perl, Python, Bash, etc to quickly connect up modules/apps, people use XML to connect services. Any app writen in any scripting language could be writen in C (or even assembly) such that it would be faster, propbably dramatically faster. On the flip side, it would take you 10 times as much time, and be harder to update/tweak/etc. XML plays a similar role. You can use it to package almost any kind of data. Both ends get to leverage a large set of tools to implement their functionality. Once it is up and running, start profiling. Where are you spending time? To much data on the wire? Compress the XML, use a binary encoding, etc. For most platforms you can just plug in a custom XML reader/writer and away you go. More likely, the bottleneck is your processing, so replace your XSLT with custom code.

I am a frim believer in building something simple that works, and then evolving it to work well. That doesn't mean you don't do back-of-the-envelope calculations before you start, and doesn't mean you don't architect a clean solution. It means start simple and leverage the tools at hand. Once it works, you can see how it actually behaves in action and start to adjust it based on actually usage. That does mean understanding that V0.1 is really little more than a prototype and thus there is a lot more work left, despite what your marketing guy may say. Just because it looks like a Ferrari doesn't mean it can corner like one.

A lot of people complain about XML being too verbose and wildly inefficient, and they are right. If we went back to the drawing board and redesigned XML today it would probably be different. If we redisigned it for their specific scenario it woudl be different still. But the fact is that it was designed 7+ years ago, which means that there are mature libraries to support it. More interestingly, nothing else has shown up which is so much better as to have replaced it. When you want a generic data format, especially when data interchange is involved, XML is your man. Worry about the verbosity and inefficiency after your prototype is done and you have sold your idea to your boss/vp/vc.

Holiday Reading

Nothing like a few hours on an airplane to help me tackle my backlog of unread books sitting on my shelves. This year? Terry Pratchet's "Monstorous Regiment" and Paul Graham's "Hackers and Painters". I read the first on my flight out to visit my parents, and the later on the return. Nice balance really, on my flight out, my mind was laden with thoughts about work, and some light brit comedy was just what the doctor ordered. On the return, I was ready to return to my real life as a computer geek. Five days with just a slow dialup on a shared phone line is hard on an internet junky like me.

Terry Pratchet's novels are far from being a bastion of serious literature. What they are is fun, quick reads. I have read most of what he has written. Some sustain themselves on TV. Me? I choose british humor. Blame my dad, really. I grew up watching brit comedy on the local PBS. Pratchet's writing is easy to read and damn smart at times, with tendency toward quirky plays on the english language that I love.

Paul Graham is what I would tend to call an 'interesting character'. An excellent communicator. Just read his essays on his personal site. He is also obviously intelligent and curious. The kind of person I tend to find most interesting. You might say that most of my good friends fit the definition of a 'Nerd' as he describes it in both his book and the essay on which that chapter is based. I like people who are more interested in doing interesting things, than in having other people think they are interesting. I enjoyed most of his book immensely (it got a little long in the tooth toward the end, I'll admit) partially because I can identify with Graham in a way. He is smarter and more accomplished than I, but the personality behind the writing was one that would likely mesh well with my friends in a casual evening. His book is full of smart observations about being a geek as well as how to leverage that to be successful. Along the way he talks about the economy, 'wealth', childhood hazing, programming languages, and how he helped create a successful startup. Very interesting read.