So you forgot about DFS and waxed the root share?

If you, like me, forget your DC is the root share for DFS then you can use the link below to wax it and start over. Dumbass.

http://support.microsoft.com/?kbid=842218

Recursive Mocking: Rhino vs NSubstitute

I'm toying with the idea of ditching Rhino mocks. I've always felt pretty lost when trying to use it and have to look up examples pretty much every time. I rarely 'mock' anything and the stubbing leaves something to be desired from the syntax and usability standpoint.

Anyway what has brought this to a head is that I'm doing a service and it has a dependency on IConfiguration. I knew/know Rhino mocks has a recursive mocking ability so I thought I'd use that.

            IConfiguration config = MockRepository.GenerateMock<IConfiguration>();

            config.Stub(x => x.Data.OurApp.ConnectionString).Return("SomeConnectionString");

            Assert.AreEqual("SomeConnectionString",config.Data.OurApp.ConnectionString);

This works as expected. However if you complicate it a little....

            IConfiguration config = MockRepository.GenerateMock<IConfiguration>();

            config.Stub(x => x.Data.OurApp.ConnectionString).Return("SomeConnectionString");

            config.Stub(x => x.Web.Sites.OurApp.Urls.ClientFiles).Return(new{new Uri("http://www.google.com"));

            Assert.AreEqual("SomeConnectionString",config.Data.OurApp.ConnectionString);

            Assert.AreEqual("http://www.google.com",config.Web.Sites.OurApp.Urls.ClientFiles.ToString());

I start to have issues and I haven't been able to find a way to get it to let me set more then one property recursively.

I just started playing with NSubstitue. Here is the same stuff/more and it works as expected.

            IConfiguration config = Substitute.For();

            config.Data.OurApp.ConnectionString.Returns("asdf");

            config.Data.OurApp2.ConnectionString.Returns("sele");

            config.Paths.PmtaDumpFolder.UncPath.Returns("uncpath");

            config.Paths.PmtaDumpFolder.LocalPath.Returns("localpath");

            config.Web.Sites.OurApp.Urls.ClientFiles.Returns(new Uri("http://www.google.com"));

            Console.WriteLine(config.Data.OurApp.ConnectionString);

            Console.WriteLine(config.Data.OurApp2.ConnectionString);

            Console.WriteLine(config.Paths.PmtaDumpFolder.UncPath);

            Console.WriteLine(config.Paths.PmtaDumpFolder.LocalPath);

            Console.WriteLine(config.Web.Sites.OurApp.Urls.ClientFiles.ToString());

Thoughts feelings?

Application Verifier: Awsome, that is all.

Get this! Windows 7 is Major version 6 minor version 1. Have fun :)

DisplayLink: How to piss of a user base

Don't jerk us around and release a god damned driver for Windows Server 2008 R2. Oh and make sure your stuff doesn't conflict with the newest Nvidia drivers.

Log Shipping: When you boss pulls the plug

So me and my boss were rooting around in the rack and he discovered that the secondary SQL server's cabling to its hard drive enclosure wasn't screwed down. He discovered this by knocking it free of course. Considering I installed them I thought he showed alot of restraint not throttling me. Anyway after we got done going over all the connections in the rack to make sure that was the only loose one we bounced the box and the RAID controller recovered with remarkable aplomb. So we went on with our chores.

This morning SQL was whining about the latency of the last backup applied to our secondary server. Basically log shipping was kaput. Running  the job by hand yielded errors, but not much in the way of info. So I did a log shipping report and manually ran a restore of the last log it had finished. I was operating on the hunch it failed to finish the last one before it was disconnected. I go the error "A previous restore operation was interrupted and did not complete processing on file". Quick Google sent me here. Apparently WITH RESTART didn't work for that guy but it worked like a charm for me. So I thought I was roll'in, but restore job failed on me again. Alot of good info to be had in msdb.log_shipping_monitor_history_detail. I also tried running the next log restore by hand and it got most of the way through before bitching about the trn being messed up. So I surmised that the copy prolly got cut off when the drives where disconnected (trn temp storage is on the same drive set). I went and got a new copy from the primary sql server and fired off the job again. Log shipping reports shows latency of last backup falling so I believe its catching up.

These boxes are both Win Srv '08 and SQL Srv '08 so you might be asking why we haven't gone to DB mirroring. I looked at it when I initially setup the servers, but the whitepapers where saying you could expect a 25% performance hit with synchronous mirroring. That was pretty unacceptable to us. Async would probably work fine but we don't want to buy the expensive version of SQL Srv. I guess I should bite the bullet at some point and setup mirroring just to test it.

Inline Sensing Variables

Ok, stop me if you've heard this one. Use Assertions in prod code to make sure your new code is doing the same thing as your old code.

I first read about sensing variables in this book, but honestly was such a newbie they really didn't register. For some reason today it dawns on me that I should revisit the subject. It was prolly the pile of legacy shiat I've got to make some rather major changes to that inspired me. Anyway over to Michael Feathers for info about sensing variables. He's also got a nifty framework for it, but its for java :( I figured I'd implement then manually for now. That wouldn't work either.

If your app, like mine, only lends itself to acceptance testing its kinda hard to implement sensing variables. You can't test it so you can't test the sensing variables. Well thats not gonna work. So what if you just add your new code and leave the old code then add assertions to make sure you new code is giving you the same thing as the old code was. I've got some acceptance tests setup so every time I run those these tests will get exercised as well. Seems like a win-win.

Anyway thats the jist what I'm going to do. Hopefully using assertions I'll be able to get it all broken out into testable chunks and they will no longer be needed at all.

BTW if you know of anybody else doing something like this or someone who thinks its stupid let me know.

I did some quick searches and came up with this tid bit. Its how to find what tests exercise a given piece of code. Kinda neat I thought. http://feedbackjunkies.com/2009/09/inline-assertion-templates-for-eclipse.html

Watin Reliability

I've been having issues with getting Watin to work reliably from our build server. IE is the biggest PITA, but FF bites me once in awhile as well.

SSL:
If, like us, you've got self signed certs on all your development boxes (build,CI,Staging) you'll have to log on as your build user and make sure that FF and IE both accept your SSL certs. FF lets you do a quick exception, but with IE you get to play around with downloading the cert and that certs root authority cert as well and installing them. There are a lot of walkthroughs about.

Default Browser:
First off if you do this:

FUUUUUUUUUUUUUUUUUUUU

Your Watin tests will hang on these for IE. I think FF keeps trucking though.

Crash Recovery:

Nice in theory, but just annoying in practice. For Watin its yet another show stopper. If you were to say, go on your build server and use something like ProcessExplorer to kill of all the IE processes that had accumulated because you are incapable of writing a test that cleans up after itself. Then you might see this. Just an off the cuff example you understand :)

And to disable:

Protected Mode:

IE apparently has something called protected mode. I don't know what it is and to tell you the truth I could give a shit. Some guy says turn it off for Watin or at least add your sites to trusted sites so they won't be run as protected mode. I've just turned it off. It is for our build user and the only place its going is our own development sites using Watin. Someguy

Thats all I've got so far. I'll keep you posted if I find any more or determine any of these are so much BS.