Sunday, February 06, 2005 - Posts
Good times: For my birthday last year, I travelled down to Atlanta to spend time with Michael and Laurie Earls. Except for having hella-headache one night, I had a blast. Anyway, here's a photo of the two us. Notice that we have similar hairlines... :)
Bad times: Little Red has been totalled. Here's the worst of it.
May not like their product much, but AB's “applause for the troops” just about made me cry. Damn. Classy and appropriate. There's a site associated with that campaign.
Second place had to be the FedEx commercial with Reynolds and the Bear.
CareerBuilder hit too close to home though.
Thanks to Kirk for pointing this out. The big take away from it the depreciated technologies list: it amazes me how much Jet is still in use.
Update: Note that SQLXML is only being depreciated out of the MDAC, not in general. More here.
Jeff Brand posts a groan about the possibility of Yet Another Workflow Framework (YAWF). And he wonders if anybody remembers “Grizzly,” the code name for a workflow system that used SQL Server 7.0 as the back end.
Continues here.
Well, it looks like I've started a new catch phrase with my rant about Glue. Didn't mean too, but as long as we're going to do it, let's be precise. In general, “Glue” is what Microsoft wants developers to do: buy or build components (or services) and build applications by “gluing” them together. There's really lots of types of “Glue” I think:
Super Glue: Anybody or anything that, when glued together, produces highly-sustainable applications with a minimum amount of effort. SOA done right is Enterprise Super Glue in my mind.
Crazy Glue: Cruft use gluing stuff up. Seems like a good idea at the time, but eventually becomes impossible to work with leaving you “stuck with it.“ The evil opposite of Super Glue.
Rubber Cement: Any component or service that's especially hard to get to “glue up right.“ Also, any application that's based on “just glue it“ that is hard to maintain or update.
JB Weld: Term used describe a case when an application has been over-designed or over-architected. “Too bad they wasted all their time welding that up when JB would have done. Comes from the product named “JB Weld.“
Duct Tape: The opposite of JB Weld, used to describe “Just Glue Its“ that really should have been designed differently to be sustainable. Differs from Crazy Glue in that Duct Tape was bad from the start.
Mort Glue: Applications constructed by “just get it done“ developers without much thought to design or reuse. Neither good nor bad, just basic.
Elvis Glue: The use Glue to add flashy, extravagant or excessive code to an application for the sake of having them around because they are “cool.“ What Jeff Brand calls “smells like glue.“ Typically bad from a sustainable standpoint.
Einstien Glue: The almost pedantic and excessive use design patterns to create gluable objects, or the use of deep knowledge of the internals of an OS, Service or Runtime to Glue in an non-obvious way. Think DDE.
Glue Gun: Visual Studio.
Glue Sniffer: Obvious, anybody that uses “just glue it” for everything if it's not the best pattern to use.
The list could go on and on and on...
Rushi, a developer on the SQL Engine Team, offers a quick introduction to SQL Server 2005 Service Broker and some reasons to use it.
Ever since Localfeeds and GeoURL crapped out, I've been looking for ways to link to local bloggers. Chandu Thota offers one based on MapPoint. Spif.
Here's me
Go submit your blog today!
Kurt Cagle makes one. Sort of. While I think Kurt is spot-on about many things -- primarily that XSLT 2.0 has real value -- I don't agree with this:
[C-Omega]... It presupposes that the appetite for XQuery will be strong enough that they can essentially build a hybrid language around it, though after having written two books on XQuery that have between them garnered less than the production costs for the books in question I'm much less inclined to agree, especially as XPath2/XSLT2 becomes much more functionally oriented.
I've said it before and I'll say it again. XPath alone is not alternative to XQuery, its a complement. There's little doubt in my mind that XPath is the way to navigate a document and when combined with XSLT, offers a powerful way to transform XML. But this navigation-based approach isn't always what you want.
Here's a simple example of why I think so highly of XQuery and why I'm glad that its in SQL Server 2005. Suppose you have a table that contains an XML-typed column of recipes. You've already decided which of those you want to make for your meals for the next week. Its market day and you want to generate a list of what and how much of each ingredient you need to buy.
If you decide to use just XPath and XSLT, you've got some work to do.
- Fetch each recipe to be used, XPath over to get its list of ingredients.
- Parse the list of ingredients into some other structure that holds description, quantity and quantity unit information. When a duplicate ingredient is found, update the just the quantity needed instead of adding a duplicate ingredient. Not easy to with XSLT.
- Serialize the aggregated ingredient list into an XML document to use as your shopping list.
That smells like glue to me.
XQuery excels in that it can do all of that work in one query against the database rather than having to write much code to do the hard work of the distinction and aggregation by hand like you'd have to with XSLT. And it can do it within the friendly confine of a database, thus avoiding the effort of coding up some client side code to do all that.
One other thing that I do agree with Kurt about though: it is disappointing to see the uptake of XQuery being less than I'd hoped. I don't think XPath and XSLT are to blame for that though. Seems thats been:
- A commonly held perception that XQuery has been slow to be standardized.
- The dearth of accessible implementations of it for Windows developers.
- Treating XML data as just another format instead of another type.
When you start seeing the value of XML as a type for data, and when you start using it as type in the database, the value of XQuery very quickly becomes real for you. SQL Server 2005 gives us a great place to start learning XQuery today.