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.

When I was setting up multi-user iTunes on my new Windows Vista box, I also came across the need to set up Picasa for multi-user support. Like iTunes, Picasa is really a single-user application so you have to do some special work to get it to share a single library across different user accounts.

Fortunately, you can use many of the same principles as in multi-user iTunes to get Picasa up and running without much issue. (Enough so that I can do some pretty easy copy/paste modification to the iTunes instructions and get Picasa instructions.)

IMPORTANT NOTES:

• This is all at your own risk.  If it doesn’t work for you, I’m sorry, but I can’t offer individual support.
• You may not be able to follow this verbatim. If these steps don’t work precisely, I recommend looking at the intent of the steps - putting the Picasa library in a central location and creating links to it from individual user profiles - and adjusting things according to your setup.
• As new versions of Picasa, Windows, etc. come out, I may not always update or catch all the little “gotchas.” I originally wrote these for Picasa 2.7… things change, versions change, OSes change, and I can’t keep these up to date for every possible combination of software.
• You must have Administrator privileges to set this up. You don’t need Admin rights once you’ve got it set up, but some of the stuff you do here needs to be run as Administrator, so make sure you can do that. 
• You need to be comfortable at a command prompt. If you’re not, this may be very frustrating for you.

Now… here’s how to get it running:

1. Get the required tools. You’ll need a tool that allows you to make symbolic directory links.
   • On Windows Vista, this is built in - the mklink command.
   • On Windows XP, you need to go to SysInternals and download a copy of “junction” if you don’t already have it and put it somewhere in your path (like the C:\WINDOWS\System32 folder); you’re going to need to use it from the command prompt later.
2. Make sure everyone runs Picasa once. For each user you want to set up, make sure they’ve run Picasa at least once so they’ve accepted the EULA and Picasa has created their initial/empty library file. You’ll also be asked to set up “watched directories” when Picasa runs the first time. I recommend watching as few directories as possible and adding them in later once you’ve finished getting everyone on board.
3. Choose the Picasa library you want to share. Decide which user’s Picasa library you want to be the main one that everyone else will share. You’ll be manipulating this library. I will call it “the main Picasa library” from now on so you know what I’m talking about.
4. [Optional] Consolidate/move the main Picasa library pictures into a shared location. Picasa allows you to backup and restore pictures using its built-in tools. You can back up from one place and restore to a different place, effectively moving your library. (I will not walk you through this. It’s sort of a pain, but if you search the Picasa forums you’ll find info.) Basically: run the backup, move your original photos out somewhere else, restore the backup to a different/new location, verify you can still see things in Picasa, and delete the original photos.  Doing this will save you a lot of headache when you find that one user can’t access all the pictures that another user can due to security restrictions. Move the pictures into a shared location (like create a folder called  C:\Users\Public\Pictures\My Pictures in Vista or the C:\Documents and Settings\All Users\Documents\My Pictures\My Pictures in XP and move it there). Note that you may need to try the “restore” operation a few times before you get it the way you like it. Don’t delete your originals until you’re sure the backup restored all of the stuff you want. I am not responsible if you lose data trying this. Do it at your own risk.
5. Find the main Picasa library. The Picasa library for each user is stored across two folders inside each user’s application data folder. Both of these are part of the library, so when you’re working with the library, copy them at the same time and keep them together.
   • In Windows XP, these folders are:
     • C:\Documents and Settings\username\Local Settings\Application Data\Google\Picasa2
     • C:\Documents and Settings\username\Local Settings\Application Data\Google\Picasa2Albums
   • In Windows Vista, these folders are:
     • C:\Users\username\AppData\Local\Google\Picasa2
     • C:\Users\username\AppData\Local\Google\Picasa2Albums
6. Back up the main Picasa library. Copy the main Picasa library folders somewhere safe for backup purposes. Just in case something goes wrong.
7. Create a shared Picasa library folder. Create a new Picasa folder that all users have access to. I recommend putting it in the “Public” or “All Users” areas so you don’t have to worry about security issues. It should be something like this: 
   • In Windows XP, this will be C:\Documents and Settings\All Users\Documents\My Pictures\Picasa Library.
   • In Windows Vista, this will be C:\Users\Public\Pictures\Picasa Library.
8. Copy the main Picasa library folders into the shared Picasa library folder. As simple as drag and drop - copy the two folders that make up the Picasa library into the new shared library folder you just created.
9. Create symbolic links to the shared Picasa library folders. You’re logged in as Administrator (or otherwise have Administrator rights), right? Here’s where you really need them.
   • Open a command prompt. In the Start -> Run box, type cmd and hit Enter. A command prompt should pop up.
   • For each user who needs to share the Picasa library…
     • Change to the user’s local settings folder.
       • In Windows XP: cd "\Documents and Settings\username\Local Settings\Application Data\Google"
       • In Windows Vista: cd "\Users\username\AppData\Local\Google"
     • Delete the old Picasa library folders and all of their contents. (This is why you backed the main library up earlier.) rmdir /s Picasa2 rmdir /s Picasa2Albums
     • Make a symbolic link to the new shared Picasa folders. This will replace the old Picasa folders and will “fake out” Picasa so it thinks it’s talking to a local user’s library.
       • In Windows XP: junction Picasa2 "C:\Documents and Settings\All Users\Documents\My Pictures\Picasa Library\Picasa2" junction Picasa2Albums "C:\Documents and Settings\All Users\Documents\My Pictures\Picasa Library\Picasa2Albums"
       • In Windows Vista: mklink /d Picasa2 "C:\Users\Public\Pictures\Picasa Library\Picasa2" mklink /d Picasa2Albums "C:\Users\Public\Pictures\Picasa Library\Picasa2Albums"
10. Verify the settings by logging each user in. Everyone you just set up should now be working off of the same Picasa library. Have each user who’s sharing log in and verify they can see the shared library. Do not use “Switch Users” - you must fully log off each user and log the next one on. They will all have to set up their own preferences (like their email settings, etc.) but they will all have access to the same picture library and the same albums.
11. [Optional] Update watched folder settings for each user. You may need to set up each user account to watch the same folders, and make sure each user isn’t watching their own personal “Pictures” folder. You only want Picasa to watch folders that every user sharing the library has access to, otherwise you could run into access issues.
12. That’s it! You’re done!

I’ve had this running for a couple of weeks now and haven’t had any issues. The toughest part really is doing the backup/restore to move your pictures to a new location that everyone can access. Just be patient with it and be willing to spend the time it takes to try it a few times. Oh, and be sure to back things up and verify your changes take hold before you delete things. You’ll get it. It’s not that bad.

All instructions here are provided for your UNSUPPORTED use and AT YOUR OWN RISK.

A fairly popular article I posted a couple years back is on setting up iTunes for multiple users on Windows. I just updated that article so it shows how to do it in XP and in Vista, and I fleshed out the steps so they’re easier to understand and follow. (I just had to do this on a new laptop we bought, so I figured I’d offer it up to folks and see if I could spread the joy.)

If you’re into the multi-user iTunes thing, check it out.