Blog Posts By Brandon

A few days ago, Jakob Nielsen posted a summary of some eye tracking studies, verifying or reiterating things we've known or suspected for years. In Banner Blindness: Old and New Findings, Nielsen reminds us that users don't see banners. In fact, his heatmaps below show that users don't even see content that looks like banners.

It turns out there are three things that attract readers' eyes more than anything else when they're reading a page:

• Plain Text
• Faces
• Cleavage

We probably could have guessed as much. There are two lessons here that we already know, but for which we can be thankful to Mr. Nielsen for reminding us.

First, content creators: make your content look like content and not like advertisements. Separate it visually AND spatially; readers are going to breeze right by it if they even suspect it's an ad.

Second, advertisers: make your ads look like cleavage, but you know this already.

If you're real quiet you can hear it: the sound of everybody and their dog talking about Silverlight. It's big, exciting news, sure. It will change the face of RIA development, sure -- if only to create some more competition. But will it take over the web? I'm not so sure.

The video demos are impressive, though I fear the DRM hoops that a Microsoft backed content-delivery platform will enable. The "drop in your javascript and see exponential speed increases" claim is a strong pull as well. Plus, I like Python, and I like anything that will give me an opportunity to write in it more often, so there's that.

I'm still not drinking the kool-aid regarding managed code in general, though, so .NET in the browser on top of a mini-CLR isn't so appealing to me. Also, I cringe every time I have to open Visual Studio, so I'm really not looking for another reason to tie myself to it. There's always text editors, I guess (incidentally, your only option if you're developing on a Mac). Lack of Linux client support is the deal breaker for me, though, as I've made the transition to Ubuntu at home, and have no intention of ever installing Vista on any machine I own.

The Buzz (well, mostly TechCrunch) is declaring everything else dead. AJAX is dead:"a bicycle next to a ferrari"; Flash/Flex is dead: "an absolute toy". And everybody else really seems to be chomping at the bit to praise Silverlight and to turn it into a golden hammer for web apps.

The ancient board game Go is the most popular board game in the world, and yet few people in the United States have even heard of it. Go is a game of metaphors: it has been compared to a fine art, a martial art, war, a conversation, life itself. Whereas Chess is a game of capturing prisoners, Go is a game of securing territory.

At it's core the rules of Go are incredibly simple: Two players (Black and White) alternate in placing a single stone on a 19x19 grid. Touching stones of the same color form a unit, which can be captured if all of the unit's neighboring spaces in both the horizontal and vertical directions are occupied by opposing stones. Grid points which are completely surrounded by stones of a single color become territory for that player. The game ends when both players pass their turn (because further moves would be of no value). The winner is determined by adding the number of points of territory plus the number of prisoners taken for each player. You can check out the American Go Association's rules page for a more detailed discussion of the rules of go.

Despite its simple rules, Go is at least PSPACE-hard, and could be as hard as EXPSPACE-complete, and the best Go programs consistently fail to perform much better than an experienced beginner. Though interesting, the computational complexity of the game of Go is not the purpose of this entry. What struck me, somewhere between the comment "software projects are like many other things in the world, like many other things in the world." on a recent entry by Jeff Atwood, and a blip about "writing code as art" by Jeremy Allison, is that the game of Go, like many other things, has something to teach about software development.

The Setup

You have a double formatted as a string with the decimal part separated from the whole part by a full-stop, e.g. "1234.9". Of course, not all cultures separate their digits the same way, and in fact, the site you're working on has a locale setting for a locale that uses a comma to separate the integer from the decimal, and vice-versa, e.g. German:"1.234,9" or French "1 234,9" style digit grouping. For the sake of argument, let's also say the decimal number is being parsed out of an XML file input by a US or UK user and that a full-stop is meant to separate the whole and fractional parts of the number.

The Problem

ASP/VBScript's clever and useful FormatNumber and FormatCurrency functions which solve oh-so-many related problems are no help:

SetLocale("de-DE")
'This is what we want (notice no quotes below)
FormatNumber(1234.9) '-> 1.234,90

'This is what we get (when using a string)
FormatNumber("1234.9") '-> 12.349,00
FormatCurrency("1234.9") ' -> 12.349,00 €
'ARGH!

When in a German locale, FormantNumber sees the string "1234.9", it assumes that the full-stop is merely a misplaced thousands separator and drops it. Though I was confused and angry at this behavior at first, I have come to see the sense that it makes (consider interpreting "1.234" in a German locale).

In an Extreme Programming environment, continuous, merciless refactoring is a way of life. Though the concept of refactoring isn't woven so tightly and explicitly into the workflow of most software developers, knowing when to stop what you're about to do and take an extra hour to rewrite a few methods or a few classes instead of adding yet another condition to that logic block could be the difference between 6 hours of head scratching and a simple in-and-out update when you see this code again 6 months from now.

If you're already working with a well written project it's frequently completely appropriate to add a few lines of code to a method or two, to pass in a new parameter, or run out and grab some additional data, and be done with it. Sometimes a bug is really just a bug: a loop is off by one, a boolean expression is incorrectly nested, some little bit of business logic was overlooked, whatever.

Sometimes though, a bug (or the process of fixing the bug) is an indication of a bigger problem. Here are 5½ signs that the patch you're about to make will cause you bigger headaches down the road if you haven't already considered and dismissed refactoring:

1: A new component doesn't seem to fit.

When you're holding a square peg and looking at a round hole, you should be asking yourself why the hole is round, instead of looking for a sledgehammer. Forcing a component into an archicture where it doesn't belong is going to cause problems now, while you try to trick the current architecture into supporting the new functionality, and it's not going to make it any easier in the future when you revisit the new component or add more new components.

Of course Visual Studio 2005 doesn't compile for .NET Framework v1.1. Of course you can't (easily) buy Visual Studio 2003 new. Who would want to do that? Well, me for one; at least until Adobe releases some Flash Remoting components for .NET v2.0.

In lieu of any built-in backwards compatibility support from Microsoft, there are a number of community solutions for Flash/Flex developers who through one circumstance or another are using VS2005 (or, of course, anybody else who wants to target v1.1 from VS2005). Microsoft has adopted MSBee as a VS Powertoy, so I guess that's as close to official as you're gonna get -- It's even got a fancy .msi installer. Jomo Fisher's blog entry explains what I suspect is going on under the hood of MSBee, and Gustavo Guerra created a build targets file that includes Mono and .NET Compact Frameworks, though it seems to be missing from Gustavo's link in that forum entry.

Of course, you could try to go the other way and fix Remoting instead of Visual Studio, which is what the developers of Flourine are trying to do with an Open Source (GNU Lesser GPL) Remoting library which supports both .NET v1.1 and v2.0. You have to build the gateway dll yourself, but once you do, you can use the wizard they provide for VS2003 or VS2005 to create and configure a project for your Remoting services.