If It's Not Information It's Just Noise

If you write code for a living, you don't have to be around very long before the subject of coding standards comes up, and it is a subject about which people tend to have very strong opinions. My own very strong opinion is that most so-called standards really are styles, and that they do not rise to the same level as standards. How many spaces you use to indent a line of code is a style (or do you use tabs?); whether your code compiles when you don't have a trailing semicolon is a standard.

Call me pedantic (you wouldn't be the first) but I think the distinction is important. When people are discussing the formatting of any given piece of code, it is easier for the proponent of a certain style (opening curly braces, for example) to get his way if he can appeal to the authority of the "standard" to support his position (reference to the logical fallacy fully intentional). Just because that person was pushy enough to get his way codified doesn't make it right, though.

Countless hours have been spent discussing, drafting, arguing about, and then conforming code to some standard or another, and that's a sad waste of time. Worse, for me anyway, is that many coding standards make code harder to read, such as requiring comments on every method, requiring regions (collapsible blocks in which code lives in a code file) around every conceivable form of code in a file and in a certain order (sometimes even where there is nothing actually *in* the blocks, or when the block already has a collapsible region with a title!), and worst of all, requiring that something like a property getter or setter take up four lines of code when it could all fit on one.

Standards that don't help your code convey something important or interesting about the code should be eliminated, at least as far as what a coder has to deal with on a day-to-day basis. If stylized code makes it easier for the source control tool to diff and merge, well, require running it through a prettifier before committing changes. Just make sure the prettifier can reverse-engineer the code back to *my* way before I have to see it!

Silverlight UIAutomation Testing -- Using WatiN to navigate to a page and White to test a Silverlight app

I had the need recently to automate testing of a Silverlight app and ran into a problem using white (could anyone have come up with a more difficult name to search on?) where white does not provide functionality to get a reference to a hyperlink in the DOM and click it in the way that, for example, WatiN does. The scenario where this came up is there is a web app with a landing page that has a link to the page hosting the Silverlight app and we need to click through the link into the Silverlight hosting page.

I briefly thought about just cribbing the functionality from WatiN and extending white's capabilities but quickly discarded that idea as too complicated and out of concern that it would become a maintenance nightmare.

The solution I came up with is to use WatiN and white together in a hybrid fashion, where WatiN spins up a browser instance and then white attaches to that browser instance using the ProcessID of the instance from WatiN. White doesn't expose an Attach method up in the InternetExplorer class where Launch lives, but it does have it down in White.Core on the Application class, so it was a simple matter to create an extension method on the InternetExplorer class to expose one that can be used in unit tests.

It goes a little like this (warning: horrible formatting):

public static class WhiteExtensions
{
// the extension method to simplify usage
public static InternetExplorerWindow Attach(
this InternetExplorer val, int processId, string title)
{
InternetExplorerFactory.Plugin();

return (InternetExplorerWindow)Application
.Attach(processId)
.GetWindow(title);
}
}

// new up a browser with WatiN
Watin.Core.IE watin = new Watin.Core.IE(url);
watin.Link(Find.ByText("foo")).Click();

// spin up white and attach to the browser that WatiN started
White.WebBrowser.InternetExplorer white = new White.WebBrowser.InternetExplorer();
white.Attach(watin.ProcessID, "browser window title");

// get the Silverlight app reference from the white browser reference
White.WebBrowser.Silverlight.SilverlightDocument sl = white.SilverlightDocument;

// do stuff
sl.Get<Button>(SearchCriteria.ByAutomationId("SomeButton")).Click();


787 First Flight

She flies!

Ender's Game come to life

Remote Control Warfare Prompts Protest

Unit Testing as an afterthought

Something you hear a lot in the development world is "We'll write unit tests if we have time," which usually means "we'll go back and take a look at the huge stack of code we are about to toss over the wall to QA and try to write tests for all of it." Quite often it is the case that some tests are better than none, but as part of a mature development process, this is the wrong way to view unit tests.

If your motivation for writing unit tests is that you do it so that you can put a check mark on a development process list, you are missing the point of writing the tests in the first place. Writing the tests as you go (as mini test harnesses to help quickly test and guide development, or immediately along with development to test edge cases and cyclomatic complexity pathways) helps you to write more accurate code more quickly, which is what most people would say their goal is in the first place when they set out to commit acts of programming on their trusting clients' code bases.

Very often it is the case that writing tests for a given piece of code leads to a much better understanding of the code under test, which helps to a) write the correct code and b) be able to explain and understand it later when you need to look at it again, or when a colleague or QA tester comes calling.

Writing unit tests is like showing your work in elementary school -- the point is not to write down an answer, it is to work through the process so that you understand what you actually are doing. And with unit tests we have an added bonus: the tests are repeatable and automatable, and they inform future developers (including the author of the code) of the intent and purpose of the code under test quickly and clearly, in a way that just reading the tested code alone cannot.

Safari performance problem fix

I found the fix for the horribly-slow performance of Safari on the Mac: google chrome.

I'm a relatively new Mac OSX user so I am still getting used to the feel of things, but after upgrading to Snow Leopard last weekend the Mac mini has been noticeably slower, especially when using Safari. I check every now and then for Chrome on the mac and until today always hit a dead end. But, there now is a pre-beta version available for public consumption (google calls the early-access release levels "Dev Channel" and "Beta Channel," where "Dev Channel" roughly equates to "alpha.")

The difference is immediately noticeable: no more wait icon when trying to create a new tab, no more waiting while the tab contents are grayed out when choosing a previous page, etc., and switching tabs is snappy. From google's description of the Dev Channel it sounds like what is reasonably stable today could at any time become unstable, but the build I am using right now is working great, so no complaints at all.

iPod Playlist Genius ain't so smart

If the iPod playlist genius is so smart, how come it's always repeating songs from playlist to playlist?