Archive for June, 2007
My MbUnit first experience
I needed to run some unit tests today against an open source project that has some written using the MbUnit fixtures. Having previously used csUnit and NUnit I felt confident the process would be a breeze. Oh how wrong I was… I decided to show the process I took as a screencast, but some of the highlights are covered below:
View the MbUnit first experience screen cast (Flash) (7MB)
Installer abandons you
No icons created for you, no getting started info, no indication of where it put files unless you caught the window on-screen for 1 second. It may as well be in ZIP format – at least you’d know where you unpacked it.
Web site “Overview” and “Getting Started” pages have nothing about running tests
Some information on creating them and what the product is about but nothing about how to actually use it or get started running tests. That is buried away below text fixture type information.
Silently failing tests in GUI tester
Once you finally make it to the GUI tester and load the assembly and hit run… should an exception fire then the GUI doesn’t so much as display an error message or even indicate a test failed. It simply says there are x number of tests to run, 0 success, 0 failed, 0 ignored and 0 skipped.
If you want to actually see indication of the error you have to head into Report whereupon the option to output to text throws another exception.
Thankfully HTML works.
Inconsistent GUI
Not as essential as the other points but still valid…
Major mismatch between context menu and main menu options. Some options available on one and not the other (NCover, Tree) and where they are available on both are named differently (Load Project becomes Load Config).
“Remove Assemblies…” does not prompt with dialog as “…” might suggest but removes All assemblies.
Given the amount of discussion I’ve seen on MbUnit I can’t help but imagine I’m missing something.
Update
It would appear the GUI has been neglected in favour of IDE integration with TestDriven.NET. It still silently fails however.
[)amien
DiffMerge is free, try it with AnkhSVN
SourceGear, known for their Vault source control software, are giving away their three-way diff & merge tool DiffMerge for Windows, Mac and Unix.
DiffMerge has a clear interface and supports for file-type specific rule-sets that allow you to decide how to deal with white-space, line-endings, encoding etc.
I’ll be using it instead of my trusty KDiff for a couple of weeks to see how things go.
To use DiffMerge in AnkhSVN head into the Tools > AnkhSVN > Edit the AnkhSVN Configuration menu option and then paste each of the following command-lines into the associated configuration option.
DiffExePath
C:\Program Files\SourceGear\DiffMerge\DiffMerge.exe "%base" "%mine" /t1="Base version" /t2="My version"MergeExePath
C:\Program Files\SourceGear\DiffMerge\DiffMerge.exe "%base" "%theirs" "%mine" /r="%merged" /t1="Base version" /t2="Their version" /t3="My version"Alternatively you might want to check out Trevor Green’s instructions on using DiffMerge with TortoiseSVN if you are not yet sold on AnkhSVN and it’s Visual Studio integration.
[)amien
Font rendering philosophies of Windows & Mac OS X
Jeff Atword asked What’s Wrong With Apple’s Font Rendering? and as I answered in the comments it comes down to philosophy:
The primary difference is that Microsoft try to align everything to whole pixels vertically and sub-pixels horizontally.
Apple just scale the font naturally – sometimes it fits into whole pixels other times it doesn’t.
This means Windows looks sharper at the expense of not actually being a very accurate representation of the text. The Mac with it’s design/DTP background is a much more accurate representation and scales more naturally than Windows which consequently jumps around a lot vertically.
Jeff and Joel both wrote follow up posts agreeing that it is one of philosophy but both are of the opinion that the Windows pixel-grid approach is the better whilst our displays are only capable of low dots-per-inch (DPI).
What they don’t seem to appreciate is the compromise this causes.
Here is an example of Times New Roman on Windows (left) and Mac OS (right) scaled over whole point sizes with sub-pixel precision:
The two thing to note here arising from this “pixel-grid is king” approach are
- Windows does not scale fonts linearly as the rough line points out
- Windows scales the height and width but not the weight of the font
Neither of these may matter to a casual user but for professionals preparing material destined for high DPI (film or print) then it’s a world of difference. How can you layout a page on-screen and expect the same result on the page when the font isn’t the same width?
The issue is reminiscent of the “I hate black bars on wide-screen films” brigade who believe that the film should be chopped, panned, scaled and otherwise distorted from the artists original intention simply so that it fits better on their display.
Typography has a rich and interesting history developed and honed over centuries. It is a shame to misrepresent typefaces especially as the pixel-grid approach becomes less relevant as displays reach higher resolutions.
Update
Some additional comparisons and a note that the gamma differences between Windows and Mac will affect how you see the “other” systems rendering on your machine.
Further update (21 August 2007)
Thanks to Daring Fireball and ZDNet we’ve had a few more great comments which I’ve summarised here:
George thinks the philosophy idea is wrong because “What percentage of Mac users sit around all day doing nothing but pre-press work?” but as Fred points out Microsoft’s desktop-user optimised rendering ends up on images and videos all over the web, thus escaping the environment for which it was crippled.
George also claims that Vista’s rendering is improved, I can’t vouch for that one way or another but from looking at his screen shots the difference there could simply be the contrast level as adjusted by the ClearType tuner.
Nathaniel believes that it’s not Microsoft’s job to manipulate a typeface and that if you want on-screen readability then choose a font designed for that such as Microsoft’s own Tahoma or Apple’s Lucida Grande.
I’d go further and say that Microsoft’s own aggression in sticking to the grid kills font choice at the regular reading size of 10/11 point by optimising everything to a generic sans or serif look:
Windows XP
Mac OS X
James points to an article called Texts Rasterization Exposures that proposes a combination of using vertical hinting only and calculating horizontally to 256 levels and has some convincing screenshots showing the benefits. Probably too late for Leopard or Vista SP1 though.
[)amien
AnkhSVN and Visual Studio 2007/2008/Orcas
A newer registry file is available to provide AnkhSVN with Visual Studio 2008 and Vista support in one.
If you are using Visual Studio 2007/2008/Orcas/9.0 you will have found that AnkhSVN 1.01 doesn’t appear in the IDE.
Like many Visual Studio add-ins AnkhSVN should work just fine but won’t appear because the installer does not write an entry for it in the 9.0 section of the registry.
In this case the specific branches are:
32-bit HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AddIns\Ankh
64-bit HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\8.0\AddIns\AnkhAll we need to do is export that section out, change the 8.0 to 9.0 and then run it back into the registry.
This technique should work for any other add-in’s you have that are only appearing in 2005.
If you installed AnkhSVN into the default folder try these registry files I have prepared for 32-bit or 64-bit machines.
[)amien