Other Stuff

Woohoo! Just got my Google Wave Account!

Adam McKee — Tue, 13 Oct 2009 20:07:39 GMT

Sorry, already promised out all of my 8 invites, so no begging :)

I agree with my buddy Rob when he says, "I hope that my dreams are not crushed when I actually start to get to use it."

I can't wait to see what kinds of neat things I can do with it! More to come, as I crash into Google Wave...

XSLT is Pure Evil

Adam McKee — Sat, 16 May 2009 05:43:05 GMT

And I don't mean the Diet Coke of Evil (only one calorie, not evil enough). I spent most of today finding out the most stupid of things.

All I wanted to do was to create a blasted <img /> tag that had its source attribute set dynamically by XSLT. Seems pretty run-of-the-mill, eh? Here's the XSLT (I've even replaced the xpath with hard-wired text to simplify the scenario):

<xsl:stylesheet version="1.0" extension-element-prefixes="msxsl" exclude-result-prefixes="msxsl js dl" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:js="urn:custom-javascript" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:dl="urn:datalist">
<xsl:output method="xml" version="1.0" omit-xml-declaration="yes" indent="yes" encoding="utf-8"/>
<xsl:template match="/" xml:space="preserve">
  <div class="sponsorLogo">
    <xsl:element name="img">
     <xsl:attribute name="src">test.gif</xsl:attribute>
   </xsl:element>
  </div>
</xsl:template>
</xsl:stylesheet>

I fired up my trusty, dusty C# transform method that I've used for quite a while, passed in the XML I want to transform with the above XSLT, and BOOM! I get this .NET runtime error:

Attribute and namespace nodes cannot be added to the parent element after a text, comment, pi, or sub-element node has already been added.

What on earth?! I've done this sort of thing many, many times, so why now? Well, here's the reason:

<xsl:template match="/" xml:space="preserve">

It turns out that this attribute tells the XSLT parser to treat the white space I was using to indent/format my xslt as actual text, which makes the above error make a lot more sense. I stripped out the xml:space="preserve" attribute, and poof, everything worked perfectly.

So, there are really two lessons to be learned here:

xml:space="preserve" treats ANY white space (to include line breaks) as actual text, so don't use it if you plan on making your XSLT readable by any human being.
Don't cut-and-paste an XSLT document from some other system without first being SURE you know what your headers are doing.

What a disaster. Now, it's time to go home. Have a good weekend, everyone.

Your Words are More Powerful Than You Think

Adam McKee — Thu, 12 Mar 2009 06:30:04 GMT

If there is ever a time to be aware of how powerful your words are, it's now.

Jonathan was sitting in his grey fabricated cube, wishing he were anywhere else. It was 9:43 PM on a Tuesday night, and his monitor was spraying that harsh, bluish off-white glow, just as it had been for the past 14 hours. Jonathan was in a foul mood, but it wasn't the long hours that bothered him, as he was accustomed to late nights at the office. He was well-paid, after all, and was grateful for his job. He enjoyed conversations with his co-workers, and thought it was pretty cool how his company let him work just about whenever he wanted to.

What was eating at Jonathan this particular Tuesday evening at 9:43 PM was that Bruce, his project manager, had just sent him the third utterly ambiguous reply to the same specific questions he'd be asking for days now, and the expectations of his client were the same as they've always been - delivery tomorrow morning at 8:00 AM. He had been working on this system for only a month now, but when you've been assigned to rescue a two-year long project that was spiraling out of control, a month seems like a year. Jonathan grumbled under his breath about how he hated this situation, and wondered how he managed to let himself get into it yet again. This time, he swore to himself, will be the last.

Jonathan was bewildered, wondering what he could have done differently to get the answers he wanted from his project manager. Was he asking the wrong questions? Why on earth was he on the hook for delivery, when it was Bruce that was mismanaging the client's expectations? Nothing seemed to make sense, especially since he was on his third 5-Hour Energy drink that day, and last night he swore to his wife that the absolute-drop-dead-worst-case scenario would leave him being back home in 17 minutes from now. And it took at least 32 minutes to get home. Great. Another fight to mediate. At least the kids will be in bed, he thought.

It was at this time that Jonathan decided that drastic measures were called for - after all, he was the one getting screwed, and there is no better time than the present to take matters into your own hands. Eric Longfield, the CEO of the company, had recently visited his office branch and reassured everyone at a power-luncheon that he had an open-door policy. If anyone were in need of anything, all they had to do was let him know, and he'd do everything in his power to see to meeting their needs. Jonathan decided to take Eric up on his offer.

Jonathan was excruciatingly careful in how he crafted his email to Eric. After all, Eric was the CEO - there was a certain reverence required when approaching him in any capacity. He detailed how his project manager didn't answer any of his questions, and how it was utterly unrealistic to expect him to deliver tomorrow. He also mentioned how he never saw any goals, and that he felt as if his work wasn't necessarily pushing towards the finish line (if there was one). Jonathan felt he had adequately communicated the gravity of the situation. He thought that surely an email that serious will absolve him of having to deliver anything, because it wasn't his fault for the project being in disarray in the first place. It was someone else’s baby, and he was just the sitter... so he thought.

The next morning, Jonathan’s mood wasn’t much better. The fight with his wife went very poorly last night (not to mention that it lasted until 1:30 AM), and he spilled his $7 mocha on the way to his car. And things only went downhill from there.

When he reached his desk, he saw his voicemail light blinking on his desk phone. One… two… three… four… five blinks? Who could have possibly left five messages between ten o’clock and seven-thirty this morning? He didn’t want to find out, but he knew he had to.

“Message one, left at... 10:02... PM… Yesterday. Hey Jonathan, it’s Eric Longfield. I tried your cell but it went straight to voicemail, so I thought I’d call you here too. I got your email, and wanted to talk to you about it. Please give me a call when you get in first thing. Thanks.”

“Message two, left at... 10:34... PM… Yesterday. Jonathan, Bruce. You were supposed to have everything done tomorrow morning, and instead of a call from you saying that you were done, I get a call from Eric Longfield. What do you mean that I’m…”

Jonathan jammed the “delete message” button as hard as he could with his thumb. He didn’t need to hear the rest of the messages. He slumped in his chair, took a deep breath, and tried to collect himself enough to hold a conversation with Eric, and hope to make amends with Bruce.

Does this story sound familiar in any way to you? How much value do you put into what you say about others? Do you find that you let situations, even the dire situations, dictate your words?

In the end, Jonathan was able to keep his job, but he had to work long and hard re-build the bridges he tore down that Tuesday night. Thankfully, Eric saw this as an opportunity to grow Jonathan, and showed him how dangerous sand-blasting really is. The project was delivered eventually, and Jonathan worked on other things, but this simple truth stuck with him:

Your words are more powerful than you think.

Backwards Engineering

Adam McKee — Fri, 13 Feb 2009 00:41:13 GMT

I heard someone say, "backwards-engineer a solution" on a conference call today. I think he meant, "reverse-engineer," but it got me thinking about when we pass "backwards-engieneering" off as "forward-thinking."

Just food for thought. I may write about this more as my fancy is struck.

Systems Design and Poker Odds

Adam McKee — Sun, 08 Feb 2009 09:15:03 GMT

Deciding whether to implement a new, unproven widget to save in development costs is a lot like deciding whether to call a player who goes all-in on the first hand of a poker game. You may land your cards, but is it really worth it?

The way to determine whether or not to take the risk with an unproven widget is a lot like how a professional would assess the scenario I just described.

An accomplished poker player knows what each hand is worth, not only in terms of the potential winnings, but in terms of how his invested chips will sway who has what equity in the game.

This same accomplished poker player will tell you that a big, early chip lead doesn't amount to anything worthwhile. In fact, if you were to double up on the first hand of the game (implying that you eliminated another player to do so), you'd end up with far less equity in the game than the face value of chips you have in front of you. This loss of equity occurs because someone being eliminated this early in the game is far more valuable to all players than the amount of chips you won by eliminating him. You won his chips, but everyone else won the benefit of having a player eliminated, and they didn't have to risk the farm to do it. Chip-for-dollar, your chips are now worth far less than everyone else's.

Now, let's apply this idea to systems design. When your tech lead promises that a widget will make the development life-cycle easier, it's always at the cost of configuration, maintenance, and/or other no-see-ums that add up very quickly come delivery time (and to top it off, they are never documented adequately, if at all). In other words, since he can't account for the the total cost of ownership (TCO) of the widget when he proposes it (hence it being unproven), he would accept the widget as a viable solution based solely on its perceived benefits without regard for the no-see-ums he'll have to wrangle.

"Saving" on development time with an unproven widget is a lot like winning that huge pot up-front. While you save in development, someone will pay for the ownership of something duct-taped together, and if you're a vendor, it will inevitably be you.

So if you are going to take a risk with an unproven widget, do yourself a favor and build an inordinate amount of time into your project plan. I mean on a factor of 4x of how fast you think you'd get it done if you were stoned, and had a mountain of cheesy poofs that demanded to be eaten.

Why Amusingly MOSS?

Adam McKee — Tue, 20 Jan 2009 06:03:56 GMT

Because you have to have a sense of humor to do what I do. Otherwise, you'd go putting forehead-shaped dents on all of the flat surfaces your office, and we can't have that.

And that, ladies and gentlemen, is exactly why I'm here, and that's why I started this blog - to save your employer money on broken office furniture and computer hardware.

I want to personally welcome you to what will become a heaping galvanized bucket-full of knowledge and wisdom regarding SharePoint, ASP.NET, Commerce Server, and various other Microsoft Technologies.

It is my sincere hope that what you get out of this blog is meaningful and actionable information to resolve your technology problems. I'm always open to comments and questions. Oh, and if you find that there is a technicality (or glaring mistake) that I have overlooked, I'm always willing to fix them.

As always, thanks for visiting!

Cheers,

Adam