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?

I am, I’m sure, somewhere around the last person to get on board with this, but still. I got The Orange Box for Xbox 360 for Christmas and, after hearing about Portal from a lot of folks, I finally got a chance to play it this weekend.

It’s awesome.

I’d played Half-Life before, and Counter-Strike, and all that, but this is way, way different. Basically, it’s a first-person puzzle game, which is something I’d never come across before.

The idea is that you are in a testing facility for a company called “Aperture Science.” You’ve got a gun that shoots, basically, “holes.” You shoot a wall, and a hole appears. Then you shoot a different wall and the other side of the hole appears. Walk through one hole, you come out the other.

Think about that for a second and imagine the possibilities - it’s not just the walls you can shoot. Shoot the ceiling and the floor, then jump in. You fall through the ceiling to the floor… through that hole and back through the ceiling… and you keep falling infinitely. Or shoot the wall across the room and the floor below you - fall through the floor and get propelled out the wall across the room.

You use your portal gun to solve puzzles in the testing facility getting from the entry to the exit of each room. As you progress, you learn more and more about the testers and Aperture Science. And then… well, you just have to play. It’s the perfect blend of difficulty, humor, fun, and originality. (The subject of the post is a reference to one of the little jokes in the game.) Plus, the song at the end credits is probably the best video game song ever.

The only problem I had with it was that it was too short. I beat the standard game in like four hours or something. After you beat it, there are challenges you unlock (advanced versions of the puzzles you just solved, challenges to see if you can beat the puzzles in a certain time limit or with a minimum number of portals, etc.), but I want more story. It was short and fantastic and I gotta have more.