Lessons Learned

Windows Azure

Randolpho St. John — Mon, 27 Oct 2008 21:40:37 GMT

So, by now you've probably heard of the Windows Azure news coming out of PDC; it's rather hard to avoid the media blitz.

It looks useful. Being able to easily deploy and scale services would be a big help, frankly -- if I could ever convince the Kool-aid drinking anti-PC Penguinistas that control our network to agree to such a system. Snowball's chance.

But I've a much more pressing issue to blog about than that. All I can think of since I heard the name is "Why???!?!? Who came up with such an aztacular name?"

UPDATE: Ok, now I'm confused. As I get deeper into Azure, it appears to only be available as a remote service from Microsoft. Is that correct? Or can enterprises purchase Azure and set up their own clouds? Further updates as I learn more.

Are You a PC?

Randolpho St. John — Fri, 26 Sep 2008 14:21:23 GMT

So it turns out I'm a PC. Are you?

I've been having trouble getting into this whole I'm a PC thing. I am a PC.

But I'm also a Mac and a Penguin.

Don't Use NOLOCK, Use HOLDLOCK

Randolpho St. John — Thu, 28 Aug 2008 14:36:23 GMT

Normally I very much agree with the things Jeff Atwood has to say. In the case of this post, however, I must take issue. What begins with a decent intro into the concept of deadlocks eventually ends with Jeff deciding to use the NOLOCK table hint to allow dirty reads of a table that had been locked by an update statement. He concludes with a complaint that Microsoft seems to think that Stack Overflow is a banking institution and therefore worthy of data integrity instead of the mere programmers blog/wiki/link exchange that it really is.

Jeff wildly misses the mark with his conclusion, in my opinion.

Not only is NOLOCK deprecated, Jeff seems to believe that data integrity is something one can safely do without "in certain scenarios". He is wrong. Every database not only deserves but requires data integrity.

Of the dozens of posts that replied to Jeff's article, a few diagnosed the real issue (long updating transactions) but only one (at least as of the time of this post) supplied the correct solution (in my opinion) to Jeff's problem. The poster's name was Filip and his blog is worth adding to your feed reader. The solution Filip pointed out is simple: Lock all your resources *before* you update them and put a waiting lock on them (HOLDLOCK) so that queries that want to use the resource wait until the update is done rather than dying petulantly.

UPDATE:

Sam Saffron (also another great addition to your feed reader) has posted an excellent rebuttal of Jeff's post explaining how and why deadlocks occur when selecting against an update and how to deal with them. Read it and remember it.

Whose Fault Are Poor Requirements?

Randolpho St. John — Tue, 29 Jul 2008 03:33:04 GMT

I had thought I would do my first Lesson Learned about my control for the upcoming Silverlight Contest, but recent events changed my mind.

A phrase has been bandied about alot at work lately, a phrase we've all heard and uttered in one form or another at least once in our software careers. It exists in numerous variations, but essentially boils down to this:

"The software is bad because the requirements were bad."

I've seen it happen far too often: somebody complains that "<x> is broken" and the original developer goes on the defensive, blaming the customer for handing him faulty requirements. "It's not my fault! The customer asked for a button that rebooted the server! All I did was give them exactly what they wanted!"

I wholeheartedly disagree with this line of thinking. Claiming bad requirements is a copout.

We as developers have a responsibiltiy to find out why every feature is requested. We must get beyond that "I press a button and it does exactly what I'm thinking" requirement to the heart of the request. If you are handed a requirements document that doesn't make sense push back. Seek clarification. Learn more about the problem domain. Call the architect and tell him he's crazy, that it'll never work. And when you finally understand what the real requirement is, write it down. Save it for posterity. Communicate it with all parties. Find common ground. It can be done.

"But my boss told me to do it that way or I'd be fired!" you might say. Very true, but that's bad management, not bad requirements. That's a different copout.

Silverlight Contest

Randolpho St. John — Fri, 25 Jul 2008 03:41:09 GMT

In case you haven't heard, there's a programming contest going on. It's the Silverlight Control Builder Contest and you've still got time to play for fabulous prizes and the awe of your fellow geeks!

I'm gonna enter. Are you? Wait, you haven't had the chance to mess around with Silverlight? Neither have I!

Won't it be fun?

So What's This Then?

Randolpho St. John — Thu, 24 Jul 2008 21:57:04 GMT

And here it is. Another blog. Seems like everyone has one these days. Except me.

...Until now.

So yeah, I've finally decided to enter the blogosphere, whatever that is. It's not like there's anything roundish about the folks who write blogs.

Except maybe near the belly.

Ahem. Where was I? Oh, yes, blogging. So yeah, I'm blogging now. Mostly this blog will involve me posting about my pain developing software and the salves I used to soothe it. It will mostly be C# oriented, 'cause that's where I spend most of my time these days, although I may spend almost as much talking about software architecture and unit tests.

I may throw in the occasional item of interest to me so be prepared for that, too, dear reader.

Whomever you are.