Sweet! I'm only two years late to the party! I just upgraded the server that hosts my site.

Greg Hughes, one of the rock stars I had the pleasure of working with on a gig has a nice phrase that he likes to whip out from time to time: trust, but verify.

Greg didn't coin the term. Wikipedia says Ronald Regan used it and others before him. The term indicates you should trust what people are doing or saying, but verify it nonetheless. I had one such opportunity recently and I'm sorry to say that I failed miserably.

The check-engine light went on in my car last Friday. I took it to a repair shop early Saturday morning and left it there. They called back in a couple of hours with an estimate to fix this, that, and the other thing. I winced, but said sure, go ahead. This is over the phone, mind you.

They called back a few hours after that and said there's one more thing. I asked for the total, winced again, and said sure, go ahead. Again, on the phone. This time, the part was offsite and the delivery truck couldn't arrive until Monday. No worries, we had the spare car thing worked out.

I get a call on Monday. The truck arrived, but not the part; weird. Apologies were offered by the repair shop, but I say, no problem, I’ll get the car on Tuesday.

Tuesday arrives and I get a call in the late afternoon. The car is ready, please come and get it. I was in a meeting, so I learned this by listening to the voice-mail the kind man left on my phone. I leave work, pick up the H-man from daycare, drive home to get the wife and drive over to the dealership.

We're less than a mile from the repair shop when I notice I have another voice-mail from them. In this one, the kind man explains that they close at 6pm, but I have until 8pm to pick up the car before the gates close. He explained that I can call him back and pay over the phone if I plan on picking up the car between 6pm and 8pm tonight. He also says the amount on the call. It's two times the amount he quoted me on Saturday. I'm instantly furious.

I park and walk into the repair shop, the service desk directs me to the cashier. The cashier grabs my file and asks for the 2X amount. I respond politely with "I can't pay that amount". She furrows her brow, understandably at 15 minutes to closing time, and returns with the service desk representative.

I ask for the amount he quoted me over the phone and he points to the 2X amount. Again, with all the politeness I can muster, as if I'm speaking to my grandma, I ask if he quoted me the 1X amount. He scratches his head and explains, it's all right there. His document identifies who called, when they called, who they talked to, and the amount of the estimate.

I'm baffled and I begin to doubt myself. But I'm also resilient and tell myself that if the man estimated 2X for the repairs, I surely would have declined and pursued other options. It's an old car and we're thinking of trading it soon. I was very sure, even now, that I asked him for the full amount. I was also sure that he never said anything resembling 2X in response to my question about the full amount. Under no circumstances could 1X be mistaken for 2X, even on a bad phone connection.

He explains that he'll have to get the manager, so he's off and I stand around for a few minutes perusing the repair sheets he left on the desk. It's all right there on the documents, how could two parties be so far apart on an essential matter?

A large burly man in a nice looking suit emerges from the back offices, introduces himself and asks me about my problem. I explain the situation and he takes it all in. Then he turns to the service representative and repeats what I said. Then he turns to me and repeats what the service manager said. Then, he repeated what the service manager said two more times, then he repeated what I said one more time followed by repeating what the service manager said and ending with a finale of "in all of my 20 years here...", you get the idea.

Those of you who have met me will know that I have a pretty good face for these types of things. I'm not too pretty, it's hard to tell what I'm thinking if I don’t let you and the whiskers don't hurt either. Plus, for whatever reason, I decided to wear a nice button-down blue shirt and dockers today. I looked professional and not like some punkass kid trying to skip out on part of the bill. Plus, I sincerely felt that I was right.

In any case, 2X is a lot of money to screw up.

The manager explains that the documents with the who-what-when-and-how-much are legal documents in the state of Oregon. I don't bite. I'm not in any mood to debate the matter. My position is clear and so is his. No quick, witty comment or sly argument from me is going to win him over. My only rebuttal is that estimates over the phone are inherently prone to these types of mistakes. He picks up on this nibble of an argument and thoroughly explains that in all his years, they've never had a problem like this. Again, I refuse to argue the point. It's futile to do so. 

So, he explains that he has to go to the general manager of the repair shop. Again, I’m left alone near the cashier's desk. This time for about 15 minutes, the standard time one would sit in an office of a car dealership, waiting to see if the manager would accept your offer on the car. The old wear-you-down trick.

In the mean time, I think about what to do. I really do like jury duty. It's a lot of fun. I wonder of small claims court would be as much fun. There's the anxiety of getting over the problem, the possibility of losing my first case (I was a business law major until I took my first computer science course in college) and just the general hassle. Plus, I'm beginning to doubt myself. Did that guy really tell me the full amount on the phone and I just wasn't paying attention? I decided that they would offer to split the difference and I'd accept it.

Damn!

So, the manager returns, right on time. He repeats what I told him; then he repeats what the service representative said one more time. Finally, the manager then says the general manager offered to split the cost with me. I asked if he was offering me 1.5X and I’m corrected. The general manager is offering it and the manager is merely saying it to me.

Whatever.

I put up the stop hand and said, I think this is the best solution for both of us. The manager knows to stop selling when the sale is over, so he turns to the cashier and firmly states that this customer is going to only pay 1.5X of the amount on the bill.

I'm relieved that the issue resolved, yet still disappointed that it happened at all. I'm out 0.5X, but I do have a few extra repairs on the car. Upon further review, I think some of the repairs are a little suspect. For example, my car is perfect on oil. It doesn't burn oil and my drive way is void of any oil spots. Why didn't I think of that when the guy said the oil pan gasket was leaking on the phone? Arrrgg!!

This is when Greg's term "trust, but verify" really became clear to me. My super smart wife pointed out that I could have asked him to e-mail me the estimate. I also could have asked him to call me back and leave the full estimate as a voice-mail on my phone if they were email-impaired. The amount of money is large enough and use of my car is important enough that I really should have been more diligent. I should have verified the estimate instead of just trusting what I heard on the phone.

Rats. Well, they say the awesome people can tell you all about their mistakes and the incompetent never see their own mistakes. Here's one more thing on the pile that I can learn from. I'm going to be riding the "trust, but verify" horse into the ground for the next couple of weeks. Apologies, in advance, to all my teammates.

I don't explain the identity of the repair shop or the amount here because you're going to trust, but verify next time right? So, in that case, it doesn't matter who I dealt with.

I was crawling around the CodePlex site and discovered a cool utility:

"Google Book Downloader is small utility which allows you to save book as PDF from google to your local filesystem."

Google has made public domain books accessible online and this .Net app can make them accessible on a plane. What will they think of next?

When I've needed to invoke a cache mechanism for data on a web site, I've happily used the ASP.Net Cache object over the past few years. It's a nice model for storing a chunk of data under a key until a specific time or for a given duration, providing the application domain doesn't recycle.

I've even hooked up some systems that resemble a Rube Goldberg apparatus to get the same features as a job scheduler, but I don't like to talk about them. ASP.Net will fire an event that you can use when something expires from the cache and therefore give you the "Cache, Wait, Expire, Do Something, Repeat" model for solving a job scheduling problem.

.Net 2.0 and up supported the SqlCacheDependency class. One of its talents is the ability to expire a cached object when the underlying database changes. Before this feature was available, you might wire up specific cache expiration logic in relevant insert, update or delete functions of your app. However, that falls short when the database is updated outside of the trip wires you set in your own code. Another application might update that database, or someone might edit the database through Query Analyzer.

Way back in the day, my team set out to bag the big beast by writing a trigger in SQL Server that would reach out an edit a text file whenever a specific table was modified. This event would be observed by the cache dependency object that was good at watching physical files for changes and ska-doosh! We've got our SQL Server cache dependency working.

Nowadays, those long, verbose methods aren't required. We've got a set of fancy new tools, namely, the SqlCacheDependency object. Or so I thought.

Its great that support goes all the way back to SQL Server 7, albeit via a costly polling mechanism. SQL Server 2005 gave us a direct feedback loop that avoided the polling system. I've know about this feature, as a concept, since it came out but only in the past few weeks have I really looked at the code to use it and I'm honestly a little shocked at the site.

I was really expecting something akin to the familiar practice of checking the cache for the existence of the object, and if necessary, repopulation of the cache. It turns out there's a few more steps, and a little craziness if you want to use LINQ to access your database.

I'll always leave the door open and hope that some day I'll learn the super easy way of doing this, but today, so much of this is in the non-trivial bucket that I'm really tempted to leave it alone and continue my current caching practices.

A year or more ago, I would reach for the data access block inside the Enterprise Library as a default choice. It's a great data access layer and sure beats writing all that goo on my own. Today, I'll reach for LINQ as my default choice. As I understand it, Microsoft is touting the Entity Framework as the future of data access, but today, I'm still sitting contently in the LINQ boat. Who knows what the future holds for me.

To be fair, the example code in MSDN that shows how to implement the SqlCacheDependency actually looks pretty good when you're creating your own Command objects. Not much to talk about there. But I was disappointed when I looked at the LINQ story. Perhaps LINQ just got out ahead too far from the pack and better things are coming.

One of the cleaner approaches to caching LINQ data I've seen was on the MSDN Code Gallery web site. Here, the developer created a sweet extension method that creates the Command object on the fly, executes the query and caches it all inside a generic method. It bears a little more review on my part, but its neat enough that I thought I'd share it. Its less than 50 lines of actual code, but they comment the crap out of it.

The whole idea of having SQL Server notify ASP.Net involves more considerations than the simplistic approach that served me well for years. For example, I can have SQL Server watch a specific table, a set of tables, or a specific query (this last options requires SQL Server 2005 or better). In addition, you'll need to start and stop the entire process when the application domain comes up and gets recycled respectively. You probably with a few lines of code in Global.asax. Finally, you're going to need a few more elements inside your config file that describe a few more details of the cache behavior. All in all, I like the direction, but I'll be happier when/if the LINQ story improves.

I'm digging the http://www.nbcolympics.com site in Silverlight. I can see sports and interviews that I'm interested in and review close plays as much as I like. I've shown this to the wife and the extended family over the weekend.

One thing that really keeping this from being the best thing ever is the user experience. For example, the Control Room is a place where I can select up to four videos to watch at once; one large and three side videos. That's really cool. However, the extended family was the real test; and they were a little frustrated.

The sucky part of the Control Room is the search interface. Here, I'm given a tiny up/down arrow at the bottom of the thumbnail stack. This is something visitors will do many times, every time they visit the site to see the next six or previous six videos in the stack. Why not make this click experience really easy to hit with big, phat arrow overlay icons? Maybe even advertise key strokes that do this. Its just really frustrating for non-technical people to use.

There's too many obfuscated clicks like this in the app. Just a few slight UX improvements would have gone a long way here. NBC Silverlight team, I give you a straight B here. Good job on the insight to give us what we want (choice in viewing Olympic events), but a "meh" job in giving me to the tools to make that choice.

There's a really cuil set of photos showing the Large Hadron Collider being setup in Europe. Very high tech stuff.

Just a little bit down from the top of the photo stack is an image of someone way down the aisle in the server room. You get the idea that there are just racks and racks and racks of servers with a mind for effective use of power consumption, space utilization, heat and all the other green elements.

The person at the end of the aisle is working on a server. They're sitting at a workstation, typing on a keyboard... looking at a monitor. Not a slick flat screen, but a huge honking cathode ray tube monitor from 1994! Hah! That thing probably takes up the space of three or four servers and gives off as much heat!

I just had a Pwop moment (the sound of a forehead slap) with LINQ:

I needed to retrieve a distinct list of years contained in a collection of objects. The data was in the form of an generic List<T>, already loaded into memory. So without thinking too much about it, I sat down and wrote a quick LINQ expression that included the Distinct() operator and since the years were actually properties on the objects, I wrote my own implementation of IEqualityComparer.

It had some problems because the resulting data was not really all that distinct, and then it happened: PWOP!

I don't need to implement an interface. I can simply use the default equality comparer for a List<int> like so.

Gah!

Behind the scenes, I see a lot of companies run on Excel and duct tape. So it's common for clients to hand me a slab of data organized into neat little rows and columns. Excel is just a handy way to throw some data over the wall and get things done. This might be a list of dealers, a collection of user profiles, product information, or anything that just needs to get somewhere else.

Depending on the scenario, I'll might massage this data and slide it into a SQL Server database or an XML file. I'm a web developer so I use the ADO.Net stack on a regular basis. If I were a Windows client developer, I might prefer to solve this problem with the Excel object model, but that really looks like more code to me, so here's how I like to roll:

The following code block accepts an Excel file path and returns an ordinary DataTable object, which can be manipulated easily by the code that calls this method. The first row of the Excel document becomes the columns in the DataTable object and each row thereafter are DataRow objects.

(Click to enlarge)

If you like, take a look at both techniques for working with Excel data and see what one speaks to you. With this block of code, I can happily accept large chunks of data from a client without spending precious time fiddling with administrivia.

What's the deal with these online social networking sites? After you sign up, they casually ask for your credentials to other locations so they can provide some handy service. Jeff Atwood noted it recently, and I've just experienced it on Plaxo. Huh... That's nice, but no thank you, and please don't ask any of my friends either.

I noticed this when I left the house this morning. Le Wife dislikes the roses due to the maintenance they require and this isn't helping matters at all.