Friday, May 14, 2004 - Posts
There seems to be a chocolate snake meme running. I'll do my part...
Maybe we should stop calling ourselves "TechEd Attendees" and adopt the term "Hearders of the Chocolate Snakes?"
Taken out today: All talked out.
# of referenced posts by category: Blogging: 2; Development: 2;
Other: 6; SQL: 1; WILY: 6
Line of the day: However, I still think that the potential is there to change the debate from a religious one into something more sophisticated dealing with the features present or missing in each.
Post of the day:
XQuery 1.0, XSLT 2.0 and XPath 2.0: The blogging continues
Note: No Take Outs tomorrow, I've got thinking to do.
While I'm not on Skype, sometimes folks will IM me with questions. Just got done with one from Daniel in Germany.
Question How do you get the number of records that a stored procedure would return without actually returning the result set to the user?
Answer Answer: Cheat!
Consider the following meager stored procedure:
alter procedure dbo.GetBeers
as
select BeerID from dbo.Beers
Here's the cheating bit. I'm actually going to execute that procedure and have the results pumped into a temporary table, which we can then query for the count.
create table #beercount
(beerid int)
insert into #beercount exec dbo.getbeers
select count(*) from #beers
drop #beercount
Brown Rice is, indeed, Ok.
First, an announcement: If you are interested, I've submitted this potential BOF session:
Title: Yukon SQLCLR: How do we all get along?
Description: Developers: Are you worried that you won't get to use all of the features and power that SQL Server 2005's (Yukon's) CLR Integration features bring to the table? DBAs, are you worried about what those crazy developers are going to want to do with the SQLCLR? What about those of us who live in both worlds? Rather than fretting and fussing about it, how about we get together and start building some understandings, commonalties and shared visions?
If you are interested, please vote for it :)
BOF sessions I'm planning on attending...
- Women Who Code : TechEd Edition
- Implementing Microsoft Content Management Server 2002
- Scripting for Systems Administrators
- Microsoft.Com Technical Communities
No really -- all I wanted to do today was write some code. I got to. But my day started by explaining the “Einstein, Elvis and Mort” trinity to a couple of co-workers. I then made this comparsion:
- Einstein can explain System.Reflection is a good thing and when you should use it.
- Elvis can play .NET like its an instrument and get it produce amazing “music.“
- Mort uses .NET as a Carpenter uses a Hammer.
I then realized that there's really a fourth class. There are people who seem to have gotten “the way” of .NET. Curse English, though, because “the way” isn't really what I want. What I really want is “
” which is really the “Michi” or “The way” in Japanese. But I'm not sure who would be a good icon for that role. Dogen-Zenji comes to mind, but that seems like it would require too much explaination. So I decided on Bruce Lee. But not the “Kung Fu“ Bruce Lee, rather the Jeet Kun Do Bruce Lee.
I picked a bad day to get all philosophical.
In 194 hours, I'll be in the air and on my way to TechEd. Yeah, I'm that
excited. This year, though, its different. I used to get really geeked up about
the sessions. This time, I'm more geeked up about the social networking. That's
going to be really hard for me though. In reality, I'm a such a people-watching
wall-flower. I'm going to have to force myself to be social.
- The more I think about Microsoft's decision not to adopt XSLT 2.0, the
more I don't like it. I understand the economics of it: the Web Data Team
has a finite number of people and amount of time. They choose to pursue
XQuery whole heartedly and I'm in 100% support of that -- in certain cases.
Notably for the SQL Server 2005 context where applications are going to be
in query-frame-of-mind. But I can also see where XSLT 2.0 would be more
natural feeling when I'm working with persisted files of XML. It sort of
feels like XQuery is being positioned as a one-tool-fits most whereas I
think good developers would rather have a good variety of tools to work
with. All that said, I'm pretty clear on what my use cases for XQuery are.
I'm not so clear on what I'd actually gain from XPath2 vs. XPath1.
- How cool would it be if Microsoft could add Dr. Michael Kay to their
portfolio of XML talent? I wonder if they've taken a run at him. I agree
with him, I think there's going to be lucrative market for an XPath2 stack
for .NET. If I that the money, I know the second business I'd be starting
up.
- I realized three or four times this week that I just can't empathize
with end-users any more and that worries me. The first and most impacting
case was during Toastmasters. Somebody was getting ready to deliver a
PowerPoint driven presentation, but had left the file on there workstation
instead of the laptop they were presenting from. I wouldn't call it panic,
but what seemed like a trivial problem to be -- going borrow a cable from
the local IT guy, plug in and go -- felt like a major deal to the presenter.
I had a really hard time understand why they felt that way. Worse, I've had
the same experience with a developer who just doesn't get XML yet. I say yet
because I know he'll get there, he just needs more experience. But I really
struggled with how to communicate exactly what I want to say to him because
I couldn't understand why he didn't get it.
- Pirsig is getting into my head. My goal is use the flight time to San
Diego to finish reading and digesting "Zen and the Art of Motorcycle
Maintenance" again. There's so much to really think about in this work. I'd
love to find MP3s or a CD version of "Lila, an Inquiry into Values" too.
- I need to start busting a nut on writing again. I really do need 34-hour
days, or I need to stop putting things off because other things are more
"important" when the really aren't.
- Somebody posed the question this week: "Iraqi Prison Scandal: Enough
already or Start the Trials?" The correct answer is both. What these folks
did was unprofessional and certainly has made our situation worse. The Court
Martial should make a strong example of them. At the same time, I can
empathize with these soldiers. In the same situation, I can certainly
understand why the situation came about and got that bad. I hate to say its
a lack of the local command's leadership, but it was: these folks should
have been lead that their actions need to be of the highest level of
professional and representation of the values of America. If we want the
Iraqis to be free, they need to think they are free. To me, one of the
things that works about the American system of Justice at a very macro level
is that people feel free to bad things understanding that their will be
consequences. Those consequences shouldn't discourage people from expressing
their freedom in socially beneficial ways. But if I were a common Iraqi, I'd
have to look at what happen and couldn't help but see more of the same but
with new people. That's should never be what our leadership asks our
Military to do, and our Military should be free to reject any such
degradation.
- Phil Wolfe and I got into a discussion about Yukon's method for dealing
with Assemblies. To put this in context: Assemblies in Yukon are registered
at the database context level, not at a globally visible level. So, suppose
you've come up with a custom type or function and you want to use it in
eight different databases. You'll have to register it each database then.
When you want to make a version change, you'll have to do that again for
each of the databases you want using the updated object. In that sense, it
would be better if there was a GAC-like concept, like, say, registering the
assembly with Master and letting everything access it. My take on why this
isn't in Yukon is three fold: first, its potentially a security issue --
maybe more psychological than technical, though; second it could be a
threading or performance issue that would blunt the benefit of using the
assembly. Lastly, it could be one of change control. It might be more
"comfortable" to an enterprise administrator to take down an application
server, make a number of changes, and bring the server back up than he or
she would be comfortable doing with a SQL Server. Phil also asked if I see
this behavior changing with SQL Server 2005 + X (next version). Too early to
tell, I think. Yes, I suppose it could. Much depends on what customers want,
though.
- That leads me to my whole understanding of Yukon: Its just a first turn
in the rotation in the big pivot. What the big pivot? Today, systems point
North (applications) and South (data). The work that people do points East
(Create) and west (Consume). Yukon's ability to treat data as an application
service aligns that product more East-West in my mind.