In an effort to save some money and get some faster net service, Jenn and I signed up to switch to Verizon FIOS. A couple of friends of mine have switched and like what they’re getting, so we’re hoping we like it, too.

That said, one of the primary reasons a lot of folks I’ve talked to have switched is that they don’t like Comcast for one reason or another. I’ve only ever had good customer service with them, so the company affinity thing isn’t really an issue. The converse is actually true - we’ve had horrible customer service experiences with Verizon, so switching, for us, is really taking a risk customer-service-wise.

Unfortunately, thus far, I’ve not been proven wrong. Even signing up was a tiring, painful experience.

(Note: Responsibility in our house is structured such that Jenn is in charge of phone, TV, and internet service, so the experience explained here was primarily hers. I was sitting right there, but it was Jenn the whole thing actually happened to, not me. I can’t imagine that it’d have been any different had it been me except there might have been more cussing.)

We started on the Verizon web site, trying to sign up for their phone/TV/internet combo deal. We’d have called, but there’s an internet-only special that they say you can only get if you sign up online. We got all the way to the confirmation stage when the phone portion of things blocked us - we couldn’t keep our phone number if we signed up online. Unacceptable. When we signed up for Comcast Digital Voice, it was a seamless experience - they took care of everything.

Jenn got into an online chat with a service rep who was absolutely no help. He reiterated that you have to sign up online or you won’t get the discount. He also maintained that they had no way to transfer phone numbers that weren’t already under Verizon control, so we’d be forced to choose a new number. Local number portability tells me otherwise.

As part of the rep’s helpful “chat,” he sent Jenn various links that, when you follow them, actually get you to run through the entire sign-up process again. She must have filled out the online form like five times and no true help (beyond the copy/paste form letter sort of chat from the online rep) was forthcoming.

Time for a phone call. We called Verizon to find out what was going on and let them know about the number portability thing. The phone rep insisted that you have to sign up online to get the discount but that one thing you could do is cancel your current phone service, get a confirmation number of some sort, and when the Verizon phone service started up, you could provide this confirmation number and keep your original phone number. That, of course, means that between the time you cancel your original phone service and the time they start the Verizon service (which could be a couple of weeks out), you don’t have a phone. Again, unacceptable. The other option we had was to register online for just internet and TV service and add the phone service later - part of the “cutover window” problem was, apparently, that they would have to run lines to our house and for some reason couldn’t run lines and cut our phone over on the same day. (Yeah, it sounded like a line of crap to me, too.)

By this time we were getting pretty frustrated with the whole thing. We wanted the bundle discount that you “only get when signing up online” but the online form wasn’t flexible enough to allow us the options we needed. There was also absolutely no help forthcoming for us on how to keep our original phone number. Jenn decided to take the route the phone rep suggested and just get net and TV service through the online form and sign up for phone later.

She filled out the form again and got to the payment screen. She filled out the payment info… and it wouldn’t accept the credit card. In fact, it wouldn’t accept any credit cards - not mine, not hers. We tried like five different (working) cards.

In a moment of last minute desperation, we placed one more phone call to Verizon. Make it or break it time - they either solve everything right now, or we’re sticking with Comcast.

This time we actually got a representative who knew what she was talking about. You don’t actually need to sign up online to get the discount. After a little conversation, we got exactly what we were hoping for to begin with - a full service conversion to Verizon services and we get to keep our phone number. No cutover window where we’ll be without service. The way it should have been to start with.

All of this took between two and three hours to get through. Two phone calls and two online chat sessions. Navigation around a nearly-impossible-to-use site with not enough options. It reminded me a lot of my recent chats with Xbox Support.

We’re signed up and we should be getting converted over on February 9. I really hope this wasn’t a sign of things to come. The reason we didn’t have Verizon phone in the first place was the poor customer service and they haven’t proven us wrong yet during this attempt to sign up. You would think the signup process - the process where a customer is literally waving money at you, asking you to take it - would be absolutely seamless. I mean, if they can’t get the signup process right, what happens when I actually have a problem?

Okay, I thought this was pretty funny:

I noticed that if you access your voice mail through the Comcast web site and delete it, if you later call up your voice mail from a phone, deleted messages show up as “skipped.” Looking at the FAQs they provide, they say something about having to empty your “deleted items” folder on the web site. But there is no “deleted items” folder. So I got into a live chat with a support rep.

Turns out there’s something weird going on, so the rep wanted a technician to look into it. That’s when this little blurb happened:

I didn’t end up giving out my password, obviously - they ended up “finding a workaround.” Hehehehehe…

I went in on Saturday for my sixth laser hair removal treatment on my face. Just like last time, I went with the MedioStar laser on the entire face (with the exception of the areas immediately around my lips, which is still a little too harsh).

While amazingly intense, the pain was actually less than it was last time. You can tell that as the hair thins out there is way less pain. In some areas where the hair is super thin, you can barely even feel it. That’s not to say it didn’t hurt, but I didn’t sweat through my shirt this time.

Even the next morning, Jenn commented on how it’s becoming a lot more obviously “patchy” on my face. You can tell where the hair has been cleared out to almost nothing. (You can also tell where the hair has stuck around - it looks sort of… zebra-like.) I anticipate getting some great results out of this latest treatment, too.

Treatments at the facility I’m with are sold in blocks of six. (That number strikes me as sort of arbitrary, but I’m sure there’s some logic to it.) I ended up getting another set of six so I can finish this thing up. I’m really getting excited with this latest progress. I haven’t torn up any sheets or pillowcases in the last couple of months (yes, one day of growth would be enough to cause destruction to anything my face came in contact with, which is one of many reasons I’m doing this).

Once it’s done, my understanding is that you still have to get “maintenance” done because as new hair follicles awaken in your skin, you can get little patches showing up. That’s a lot less of a problem, particularly since the cost of the maintenance treatments is less than a third of what the initial treatments cost and, with the hair pretty much gone, the pain really won’t be there.

Design for testability vs. API as a deliverable (or test-what’s-designed) is something I’ve blogged about before and it does sort of boil down to a religious debate. I’m currently on the “test what’s designed” side because, for me, API is a deliverable. I’m also not a big fan of some of the sacrifices you have to make when you design for testability, like losing your encapsulation.

Regardless of your views, mocking is still something you can most likely take advantage of in your unit tests. You could use one of the open source frameworks out there like Rhino.Mocks. It’ll work. If you have access to TypeMock, though, or if your project already has TypeMock in it, there’s no need to move away from it or be scared that it’s “too powerful.”

You can still design for testability using TypeMock. You just need to follow one simple rule:

Restrict your TypeMock use to “Natural” mocks.

That’s it. That’s the secret. As long as you stick to the TypeMock RecorderManager and RecordExpectations objects when setting your mocks up, only using “Natural” mocks, you can still satisfy your design-for-testability urges.

And, hey, it doesn’t hurt that you’ll be able to do those more powerful things should you need to, right?

I’ve been writing a lot of build scripts and custom build tasks in both NAnt and MSBuild lately and, based on this experience, I’ve decided I like NAnt a lot more than MSBuild. Here’s why:

• NAnt lets you run tasks before any targets run; MSBuild doesn’t. I commonly have some “setup” actions that need to happen before anything else in a build script happens. Stuff like registering NCover or starting up TypeMock. It’s stuff that needs to happen once, before any other target runs. In NAnt, I can put all of that stuff at the top of the build script, outside any target, and it’ll all get run. In MSBuild, every task has to be inside a target, so I have to make sure that every single target in my build script depends on my “setup” target.

• NAnt custom tasks can interact with build properties; MSBuild custom tasks can’t.Some of the custom task stuff I want to do is to make things easy for people by letting them set up properties in the environment and having things “just work.” For example, a task to generate an AssemblyInfo.cs file with assembly version information already populated based on CruiseControl settings might look for the CCNetLabel property in the environment and set things up automatically based on that.

  In a NAnt custom task, I have access to the full set of properties inherently. MSBuild custom tasks are entirely isolated so I need to manually pass that in as a parameter from my script.

  One parameter isn’t so bad - but what if you want to perform logic in your task based on five or six parameters? 10?

• NAnt properties are manipulated in a consistent fashion; MSBuild properties are handled differently in different contexts. In NAnt, I can create or change a property just by calling the <property> task. In MSBuild, it’s different if I’m outside of a target (<PropertyGroup>) or inside a target (<CreateProperty>). This inconsistency makes for a difficult learning curve.
• NAnt wildcards, when dealing with the filesystem, match both files and folders; MSBuild wildcards only match files. This is a heck of a problem when you want to create a dynamic item list in MSBuild of folders you want to clean up. You can’t just delete “**/bin” - you have to manually locate every single one.
• NAnt allows you to load an entire assembly’s worth of tasks at once; MSBuild requires each task to be separately loaded. In NAnt, I do <loadtasks> on an assembly and I’ve got all of the tasks in the assembly at my disposal. In MSBuild, I have to do a <UsingTask> for every single task I’m using.

• NAnt includes task assemblies in the executing AppDomain; MSBuild doesn’t. This is a problem if you have one custom task assembly that references another custom task assembly. Say you have custom task MyDerivedTask that is a derived/modified version of SomeBaseTask. They’re in separate assemblies. Maybe SomeBaseTask is in a third-party assembly I don’t want to (or can’t) redistribute.

  In NAnt, I can <loadtasks> on both custom task assemblies and everything is okay. When I call MyDerivedTask, the assembly containing SomeBaseTask is found and everything is good.

  In MSBuild, even if I do a <UsingTask> on SomeBaseTask to include it, I can’t <UsingTask> the MyDerivedTask unless my custom task assembly is in the same folder as the assembly containing SomeBaseTask. If I do, the <UsingTask> on MyDerivedTask will throw an exception saying it can’t find the assembly containing SomeBaseTask.

I mean, I get the whole “side-effect free” concept behind “isolating” the MSBuild tasks and everything, but it seems like NAnt is so vastly more flexible without it. Is there something I’m missing? Some development philosophy they had when coming up with MSBuild that will put all this into perspective and make me see why MSBuild is so much better? Or am I right? Does NAnt really whip MSBuild’s behind in almost every area?