ToddHa's WebLog

Live Mesh for Mac tip : Quickly Add New Folders to your Mesh

2008-11-07T00:12:53Z

Here's a tip on how to quickly add an existing folder to your Mesh.

1. Make sure Live Mesh is running, signed in, and the device has been added to your Mesh. (this is the basic stuff)

2. Select a folder in Finder and drag it to the Live Mesh icon in your dock.

3. Click OK.

That's it!

*excuse the crudity of my pictures, I whipped them up in MS Paint. :)

PDC 2008 Sessions

2008-10-31T22:12:00Z

If you didn't get a chance to go to PDC this past week, you can take a watch a bunch (all?) of the sesions over at MicrosoftPDC.com. Although I've only watched one so far (I'm working on this one right now), I will say I thoroughly enjoyed Daniel Moth's session regarding Parallel Programming for Managed Developers with the Next Version of MS Visual Studio. Note that it requires Silverlight 2.0 installed, but you can install that on your Windows or Mac.

Personally, I'm going to go through the new Windows 7 sessions, the Live Mesh sessions, and the Windows Home Server sessions.

Now if I could only figure out a way to watch this on my mobile phone so that I can watch it on my hour long bus ride back and forth to work every day... Sure, they have WiFi on our buses, but I rarely want to whip out my laptop and wedge it between me and the seat in front of me.

Across the [technological] pond

2008-10-09T23:50:00Z

I haven't been writing much here recently for a few reasons.

1. Seattle is *very* nice in the summer time. Why stay inside blogging when you can go to the Center for Wooden Boats in Lake Union, Pike Place market, or take a ferry to Bainbridge?

2. Got married. We got married back home in Kansas City which took a while to plan for, especially since we were doing it all long distance. Afterwards we went to San Francisco for a few days and took the Coast Starlight train back. It's a very pretty ride, but I recommend you get a sleeper car. It's hard to sleep in coach and you don't get all the dining benefits the sleeper car has.

3. Changed jobs. I'm working on the Mac client for Live Mesh. I found the perfect job; not only do I get to work on UI and client code, but I get to spend my day on Macs (and sometimes PCs). Sure, compared to what I'm used to, the APIs are all different, the language is different, the OS is different, but that's the fun of it.

The ABCDs of being understood

2008-07-29T20:48:00Z

A quick note : never say "crud" in a meeting if the thing you are speaking about has anything to do with reading or writing data.

For example, I was just in a meeting when somebody said, "This does a lot of crud...there's all this crud here...". In the picture were a few data components, and he was literally (I think) using the term "crud" to refer to "stuff". The problem is I had to stop try to figure out if he was talking about other components and interworkings in the picture, or if he meant "CRUD" (Create, Read, Update, Delete). This makes listeners focus on the wrong part of what you're trying to say.

Wikipedia : CRUD

Helpful Thesaurus 101

Instead of "crud" (in the truest sense of the word), say instead:

stuff
clutter
things
crap
mess
interworkings

On the flip side, Instead of "CRUD", say instead:

[data] operations
data management

[I hate explaining things like this, but the title is a play off of "The ABCs of ..." and "ABCD", which is a synonym for CRUD, and stands for Add, Browse, Change, Delete.

High Contrast Settings for Visual Studio

2008-07-02T20:04:27Z

Every person has a set of tools and whatnot for their development environment that they use & have grown accustomed to. For example, a couple of (publicly available) tools that I use day in and day out are TextPad and Beyond Compare. Another "tool" that I absolutely have to have is my Visual Studio font settings. At the end of the day, they look like this:

(Note that the code is actually for one of my work-in-progress side projects--a card game--and not Microsoft code).

As you can see, it's white on black, as opposed to the standard black on white schema. It makes it much easier for my eyes to see. The font settings are still a work in progress as well, but as I haven't really touched them in a while, I'm posting them here. They theoretically should work in all versions of Visual Studio 2008, but no promises.

To import the code:

Copy the above code & paste it into a new file. Save with the extension .vssettings.
In Visual Studio, go to Tools -> Import and Export Settings.
Select "Import selected environment settings".
Backup your current settings.
Browse to where you saved the file in step 1. Click Next.
Ensure that All Settings -> Options -> Environment -> Fonts and Colors is checked.
Click Finish.

That should be it!

Unblock? Try Unzip!

2008-06-26T23:19:00Z

I downloaded some files from the internet the other day and it didn't have an installer. I copied them into my Program Files directory (I made a new folder), and created a shortcut to them. Unfortunately, every time I ran the application, I was confronted with a dialog asking me if I really wanted to run this file, as it was downloaded from the internet.

So what I did is right click the file, click properties, and click "Unblock". This takes a long time, especially if you have a few hundred files to unblock. Also, this won't take effect unless you have permissions to those files. For example, if you install a program (i.e. Process Explorer) and you've already copied it to the program files directory as administrator, and your explorer isn't running as admin, you won't be able to unblock those files. You can click unblock and it will look like it worked, but the next time you right click and click properties, it will still be blocked.

My solution was to select all of the files & directories I wanted to unblock, right click, add it to a zip file. Delete the old files, and extract the zip file to the same directory structure. All files are now unblocked without having to manually click unblock on each file.

UnitTest.Musings.Random()

2008-06-08T22:16:41Z

While I was doing some chores today, I began to have random musings about unit tests. It's strange how one's mind works while doing (mostly) manual labor.

Separating Code Coverage by Target

It's hard to get actual code coverage numbers for a specific target (i.e. class) without getting code coverage from others. Normally one writes unit tests to cover a single class. For example, I might have a class which represents a hand of cards, and in that class I might have a function which gets, as a string value, every card in the class :

   public class Hand     
{  
    private Card[] cards;      
    ...       
    public override string ToString()       
    {       
        StringBuilder sb = new StringBuilder();       
        foreach (Card card in cards)       
        {       
            sb.Append(card.ToString());       
        }       
      
        return sb.ToString();       
    }       
    ...       
}

So if I wrote a unit test that covered the ToString function, I'd also cover a bit of the Card class. Once you amount a plethora of unit tests, you won't know what you explicitly have unit tests for and what you don't. You might say, well, as long as it's covered, I can see which lines of code aren't and write tests to explicitly cover those. That's not recommended for a few reasons -- like what happens if the code above changes and doesn't call Card::ToString() anymore? You might not notice that you lost a few percentage of coverage. And then what if Card::ToString gets a bug introduced that doesn't get caught, because the developers think that the ToString method is called from somewhere else in some other unit test? They may be caring developers and run all unit tests and inspect all of the code coverage numbers before and after, but odds are they won't.

What you really want is a way to tell the unit tests "Hey, from these set of tests only grab code coverage numbers from this target (i.e. function, class, etc.). I don't want to know about the other things it touches besides what I explicitly say." It's possible that I could get a large code coverage number simply by calling a simple button->click!

100% Code Coverage Myth

This is a common one, but I'll take a moment and rehash it. 100% code coverage is great, don't get me wrong. But what about the code you didn't write, the case you didn't handle, the data validation exception you didn't think to throw. I can easily get 100% code coverage of the Hand class above. But what happens if I do something easy to look for, like don't initialize cards? What if cards is initialized but the null is stored in the array at a few positions?

Again, 100% coverage is great, but it doesn't make me feel any better about the quality of the code. If somebody were to come to me and say that they hit 100% C.C., I'll tell them that their code probably isn't complete. And if it is (which is almost as hard as proving P==NP), then they either spent a lot of time on it, or it's not a whole lot of code.

Good(!!) Unit Tests

It's super important to write really good unit tests. By that I mean make sure you verify as much as possible without getting out of the scope of the tests. Don't check side effects in other target (as those might change), but DO check as much as you can in the current target.

I ran into this problem this week. I was looking to figure out why we had a bug and why we didn't catch it. So I looked at the unit tests that covered the feature that had the bug. I made sure that I wrote a unit test that covered the bug and ran the unit test. For the results, I used some built in functions that did the validation for me. "Interesting...it works! That's not right..." So I debugged it and followed it along. I could see that the data wasn't correct, so I continued tracing to see why it thought it was. I uncovered the following snippet of code (names changed to protect the innocent):

   SomeObject actualItem = datastore.GetObjectById(expectedItem.Id);      
Debug.WriteLine(expectedItem.ToString());       
Debug.WriteLine(actualItem.ToString());       
Assert.IsNotNull(actualItem);

Hm. He was checking that the item in the data store exists. But he didn't check that it was actually the correct data. This unit test went ALMOST all of the way, but it looks like the developer forgot to write the critical line :

   Assert.AreEqual<SomeObject>(actualItem, expectedItem);

So I added the line to the verification, and found that a half of the unit tests, including my new one, failed. Wow! So I fixed the bug, went back and ran the unit tests again. All still failed! Why? It turns out that I had encountered two more bugs that hadn't been caught yet.

Hence why writing good(!!) unit tests is important.

A Unit Test's Brevity

A coworker and I often challenge each other on this point. I believe that shorter unit tests are better. My idea is to create some basic unit test runtime which you can use to create all of your objects in a few lines of code, which allows you to get quickly to what's really important. Additionally, you may even be able to write functions which simplify the validation of the data. Sure, you could use AreEqual, but maybe you want to spit out to the debug output what each object is before the AreEqual call? What if you have to read it from a service? He doesn't have an objection to this part at all.

However, he believes that writing longer unit tests are better (in general). "While I'm here checking Z, I might as well check W, X, and Y." That way I can pack it all into one unit test. My argument is that, while checking W, X, and Y while you're checking Z, this is only good if W, X, and Y never change. Plus, you really need separate tests for W, X, and Y. That way if W passes but X and Y don't, you're not debugging through large piles of code. You know "Hey, X didn't pass, so I better take a look at that piece of code first instead of W or Y." Beyond that, if you're duplicating these unit tests in others, when one validation changes, the others have to change as well -- unless you duplicate it, but then you're duplicating a bunch of hopefully verbose code all over the place. Even putting extra validation function calls often makes it confusing what exactly the unit test is supposed to be testing. What if the maintainer doesn't understand the unit test's point (due to commenting, naming of the test, etc.) and removes the key validation point that was the actual meat of the unit test? Unit tests being easy to understand is key for maintaining that code.

Another pretty unimportant thought I just had is that if the unit tests are super beefy, it's POSSIBLE that you'll run past the unit test timeout you've defined, if you follow the point that unit tests should check as much as possible for your target. If it takes 5 seconds to check each object and your unit test is 2 minutes per unit test, you may run out of time.

A Very Clever URL Joke

2008-05-02T01:01:00Z

I was randomly browsing XKCD the other day, and saw something funny. If you go to http://xkcd.com/405/ and click on the Previous button, you're taken to http://xkcd.com/403/. If you click Next from there you're taken back to http://xkcd.com/405/. If you click Previous a bunch, you'll see that you're taken to 402, 401, 400, 399, 398, etc. And vice versa for clicking on Next.

See anything strange?

(Answer) :)

Hello World, Windows Mobile setup style

2008-04-22T04:28:00Z

One of the items that I haven't found a whole lot of talk about online or in books is how to write a custom installer for Windows Mobile, so I'm going to briefly talk about how to set one up.

Why would you want to do this? The reasons seem simple enough, but the reason I ran into this was that I wanted to explicitly check to ensure that the .NET Compact Framework 3.5 was installed on the device before you try to install the application. Note that I don't block you from installing, just let you know that you need it.

My steps assume a couple of things :
- you have Visual Studio installed with the Smart Device programmability and C++.
- you have at least a little knowledge about C++.
- you can use Visual Studio.
- you have an existing solution with a Smart Device CAB project (found under "Other Project Types, "Smart Device CAB project").

Add a new project to your solution. Under "Other Languages", "Visual C++", "Win32 Smart Device Project."

A wizard will appear. Pick your platform of choice. On the next page, pick the application type of "DLL" and check the "Empty Project" text box. Click finish, and you should end up with something like what's shown.

Right click the Source Files and add a new item. Pick "Module-Definition File (.def)" and enter a name. I picked Exports.def. Open this file and add the following:

EXPORTS Install_Init Install_Exit Uninstall_Init Uninstall_Exit

Save and close the file. Add another source file; this time make it a C++ File (.cpp). I named mine Installer.cpp. Open and paste the following code. This code defines the 4 exports we defined earlier.

#include <windows.h> #include "ce_setup.h" codeINSTALL_INITInstall_Init( HWND hwndParent, BOOL fFirstCall, BOOL fPreviouslyInstalled, LPCTSTR pszInstallDir) { MessageBox( hwndParent, TEXT("Hello world!"), TEXT("Hello world."), MB_OK); return codeINSTALL_INIT_CONTINUE; } codeINSTALL_EXIT Install_Exit( HWND hwndParent, LPCTSTR pszInstallDir, WORD cFailedDirs, WORD cFailedFiles, WORD cFailedRegKeys, WORD cFailedRegVals, WORD cFailedShortcuts) { return codeINSTALL_EXIT_DONE; } codeUNINSTALL_INIT Uninstall_Init(HWND hwndParent, LPCTSTR pszInstallDir) { return codeUNINSTALL_INIT_CONTINUE; } codeUNINSTALL_EXIT Uninstall_Exit(HWND hwndParent) { return codeUNINSTALL_EXIT_DONE; }

Now the previous code doesn't do a whole lot. It simply displays a message box when it starts to install. The four hooks are

1. Install is starting.
2. Install has finished.
3. Uninstall is starting.
4. Uninstall has finished.

All of the function definitions are defined in the "ce_setup.h" file we included earlier. For more information, you can go to (for Windows Mobile 5 Pocket PC) %ProgramFiles%\Windows Mobile 5.0 SDK R2\PocketPC\Include\Arm4vi\ce_setup.h). It explains in details all of the different codes you can return and what they mean.

At this point everything the C++ project should build.

We must include the custom setup DLL as one of the items installed. Right click the setup project you have and click View File System. In the Application Folder, Add Project Output of the Primary Output of your C++ project.

Go back to Solution Explorer and click on the setup project. In the properties window, one of the settings is "CE Setup DLL". Click this drop down box and click browse. Select the primary output in the Application Folder and click OK.

Now build and everything should be ready to go! I copied the CAB file over to the emulator and ran it and got the following:

That should give you a basic starting point for writing custom Windows Mobile installers! Note that I chose the Pocket PC as it traditionally is much less locked down than Smartphone. With a non-one tier Smartphone, there are a few more hoops to jump through.

Fun stuff:

Disclaimer

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Subtle mistakes are often the worst

2008-04-16T11:08:32Z

A few weeks ago, I noticed that some of my installs on my laptop started failing. I thought it was odd, but most of the things I install are pre-beta, so I figured that they hadn't yet started to support Windows Server 2008. Some things, out of beta, like Windows Live Writer, don't support 2k8 at all, so my laptop is set up to dual boot between 2k8 and Vista. Strangely enough, the installs were often failing during the very beginning of the setup process. One such install that failed was the Silverlight 2 Beta 1 SDK.

[Un?]Fortunately, it was the first of many installers to actually give me good information and tell me that it couldn't write the installation log to the temp directory. I had plenty of hard drive space, so I took a look at what my environment variables were for TEMP and TMP so I could look at the permissions of that folder.

What I saw (and isn't pictured), is that my user variables were set to:

TEMP=%USERPROFILE%\AppData\Local\Temp;C:\Progra~1\Python25
TMP=%USERPROFILE%\AppData\Local\Temp

Aha! The problem is so obvious now. A few weeks ago I installed Python. Python doesn't add itself to your path, so if you want to have access to it from anywhere, you need to add the Python install directory to your PATH variable. Apparently, I had tried doing this.

Unfortunately, the UI you are presented with could use some ... tweaking. Notice that there are two sets of New, Edit, and Delete buttons, all with different hot keys. If you expect Alt+E to be Edit, you're correct. However, you're incorrect if you think it will edit the item that is selected and focused. When I hit Alt+E, it always edits the selected User variable, regardless of what is focused.

It's a pretty poor UI, but fortunately it's one that most mainstream users won't need to see very often, if ever. And all others (like me) should take more time in editing their environment variables to make sure they are correct!

By the power of Grayskull!

2008-04-12T00:30:00Z

If you spend as much time as I do in Visual Studio TF, there are certain things you may find a tad bit frustrating : timeouts, connecting to the server, etc. Fortunately the Visual Studio guys/gals have come up with a set of power tools which you can download here :

Visual Studio Team System 2008 Team Foundation Server Power Tools - December 2007 Release

http://www.microsoft.com/downloads/details.aspx?familyid=7574836F-4A0B-454F-A340-85DA4698177C&displaylang=en

Included of note
- Build Notification System Tray tool
- TFS Best Practices Analyzer
- tfpt command line tool

The TFPT command line tool is pretty nice, it includes something called TweakUI, which allows you to set things like timeouts, whether or not to connect to the server on startup, and concurrent connections to the server.

I also find the build system tray tool pretty useful, so you're always aware of the build state.

Changing the default compare tool in Visual Studio TF

2008-04-04T21:49:00Z

I ran across this today from James Manning's blog and found it insanely useful. The default compare tool in Visual Studio TF is fine but I personally want some more features. If you have your own preferred compare tool, you can plug it in here:

http://blogs.msdn.com/jmanning/articles/535573.aspx

Personally, I've been using Beyond Compare 2 for years and love that I can integrate it back into my daily routine.

Microsoft Codename "Oslo"

2008-02-04T21:10:00Z

So I may have missed this, but this is what I'm working on.

http://www.microsoft.com/soa/products/oslo.aspx

It's basically a bunch of stuff that ships in:

- BizTalk Server "version 6"

- System Center "version 5"

- Visual Studio "version 10"

- .NET Framework "version 4"

- BizTalk Services "version 1"

At a high level, we ensure that everything we ship across this release works together, we find pain points early on to drive fixes back into the products before release, and drive new requirements into the teams.

To understand a bit more, my team's blog is at

http://blogs.msdn.com/e2eblog/

There's a post from my PUM talking somewhat about who we are and what we do in more detail.

When Fixes Cause Problems

2007-11-30T04:46:41Z

Note that there are tons of stories about backwards compatibility; for some of the best go see Raymond.

For a sample application that I'm writing, I'm using .NET CF 3.5. I had upgraded from the version shipped with Visual Studio 2008 Beta2 to the one shipped in VS2k8 RC1, and I hadn't had any problems. Take note, because if you've written some buggy code and are unaware of it, this may affect you, too (perhaps even coming from .NET CF 2.0 code).

This morning, I upgraded from VS2k8 RC1 to VS2k8 RTM and all of a sudden, none of my network requests were working -- they ALL timed out.

I kind of freaked out for a bit, thinking that it couldn't have been my code -- I didn't change anything! Plus, as a developer, I've learned the hard and fast rule that it's never my code -- it's always somebody else's. :) However, I was on a new machine, so I hadn't set up ActiveSync to my emulator. I convinced myself that AS was having issues and my PocketPC phone wasn't getting good service.

An hour or so later, I realized it was my code.

In my app, I have a rudimentary BizTalk Connectivity Services aware engine (although isn't specific, as it uses simple HTTP PUT/GET/POST) which takes a URL. This URL is given by the user, so there has to be some checking done on it. Mostly, this is done for me by the framework, but the one key addition which I added was checking to ensure that the URL had a trailing '/' at the end.

Thus,

http://connect.biztalk.net/services/username/service

turns into

http://connect.biztalk.net/services/username/service/

Then, internally my operations all have corresponding URL I should append to the end. However, the bug in my code was that all of the URL operations START with a forward slash. So after I glued the different pieces of the URL together

"http://connect.biztalk.net/services/username/service/" + "/Operation"

I would get:

http://connect.biztalk.net/services/username/service//Operation

Apparently in the older versions, this would work fine. But in the version shipping with VS2k8 RTM, it won't work. Simple fix, but caused havok with me for a while. Fortunately, I hadn't released it, so it was easy enough to catch and fix.

Windows Mobile App Feedback

2007-10-22T22:28:41Z

This is a question for those of you who write Windows Mobile applications (preferably managed, but native is fine too). We're developing a managed Windows Mobile application, and one of the issues we've run into is that we'd like to support both Smartphones and Pocket PCs (or WM6 Standard and WM6 professional devices, respectively).

My first WM application was a Sudoku game I wrote that worked fine on both Smartphones and PocketPCs, but it was in my spare time. I didn't handle things like text input (A-Z, a-z, symbols, etc), localization, and Pocket PC input panels. I also wrote all of my own controls (of which there was exactly 1). I also didn't get code coverage numbers (a new post on that later this week).

Unfortunately, there are some differences that make it hard to have one binary running on both. For example, we resize appropriately when the InputPanel control on the PocketPC is shown, but obviously, it's not required on the Smartphone. Another common problem we have is setting keyboard shortcuts. We want to make sure the application experience is great, regardless of whether you're on T-9 device or have a full fledged keyboard with touch screen.

My current thought is have mostly the same source, but reinvent certain controls like the StatusBar and ComboBox so that they work and are accessible on both platforms. Then I'll have one primary project and have two outputs : one for Smartphone (with a custom set of #defines), and one for PocketPC (with its own set of #defines).

So my question is:

What do others do, and what do you recommend?

I'm looking for both advice and personal experiences while developing a WM app.

Thanks!

Edit: To be clear, my plan is to have one primary project targeting the PPC, and one "ghost" project which targets Smartphone. All of the "ghost" project's files will actually be links to the primary project's files.