Semantics has no place in code Thursday, September 25, 2008

Semantics has no place in code. Ideally, code would have exactly one way of doing any given thing. In the world of data, we strive to be complete, unambiguous and exact. The world, as far as my code is concerned, is exactly as big as I tell it to be, and could only be so. What I define exists only insofar as I have defined it. The code expresses the sum-total of that world. To allow any sort of semantic nuance, we undermine the Platonic perfection of that world. I think the ideal should be to have a one-to-one relationship between virtual entities and the code that expresses them. This way, we can point at the code and say: "This is what it is."

The Unix Philosophy Tuesday, January 29, 2008

This is one of the most concise and practical articles on technical philosophy I have ever read. It's an excerpt from The Art of Unix Programming (that's a full-text link; Amazon link here) and it describes an overall methodology for solving complex programming problems: keep it simple. Effective software isn't cute, it isn't clever, and it isn't hard to understand. Effective software is written such that it does precisely what it is supposed to – no more and no less. Computers are tools that help us do human work; each piece in the workflow chain should work as expected or tell us why it cannot. The human sitting at the keyboard should understand what is happening so that computer can assist him.

Being a man who has sold his soul to Microsoft, you might think this a strange recommendation. After all, isn't the Redmond Behemoth known for at least stretching (if not throttling, bludgeoning and stomping on) these rules of minimalism? Perhaps. But I think what Microsoft has done well is demonstrate to the programming community that "least astonishment" from a user point of view is something quite different from what it means to an engineer. I recommend every programmer of every stripe read The Basics of the Unix Philosophy.

Displaying Embedded Images in a WebBrowser Control Wednesday, March 14, 2007

The application that I'm developing at work is built in Visual Studio 2005 and uses an embedded WebBrowser control to display some of its information (and to think: I left a web development position to get away from JavaScript and HTML). I want to display images in the browser, but I don't have a file share or a web server to store the files.

Well it turns out that you can display images stored as embedded resources in the browser using the "res:" protocol, but this only works on old Win32 resources. I had read about this in various places, but couldn't find enough information to actually get it working until yesterday, so I figured I'd share the information here (good a place as any) for future developers to benefit from my labor. Remember, this is only for Visual Studio 2005 and .NET 2.0.

First, you've got to embed the native resources into your assembly, which I thought would be the hard part, but it's not. I've adapted my procedure below from this post at the MSDN forums. The only thing that may not be obvious is that there is only native support for BMPs and ICOs; GIFs and JPGs are considered "custom" resources. To add a GIF:

1. In Visual Studio, choose File -> New -> File
2. Under the General node, select Native Resource Template and click Open
3. In the Designer window, right-click the ResTempl1.rct node and click Add Resource
4. In the Add Resource dialog, click Import...
5. Find your image file and double-click it
6. When prompted for a resource type, enter GIF

To reference this image in your HTML, you use the file name of the assembly (blah.dll or blah.exe), the resource type identifier (in our case, "GIF"), and the resource ID. The format of "res:" URLs is described in detail here (found via a different MSDN forum post). This is the best article I've been able to find on the topic and it has very readable and complete explanations.

Generally, the format for the URL is res://[assembly file name]/[resource type]/[resource ID]. The resource ID is expected to be prefixed by a hash symbol (#), but the hash is a special character in URLs, so it needs to be escaped as %23. This makes your URL read like this: res://foo.dll/GIF/%23103 if your assembly is called foo.dll, your type is "GIF" and your resource ID is 103.

And there you have it. I hope this helps some other poor shlub trying to work his way through this problem.