People have used the “Lu” prefix on database tables since time eternal, but it means very different things to different people. I’m reading a specification right now that has 24 tables; 18 of them are “lookup” tables. Several of these can be configured from within the application. I find that weird.

Here’s my view:

A table is always considered “lookup” if adding or removing rows, or changing their meaning, would break the application, or result in unexpected behavior. For instance, a table that corresponds to a status enumeration in the code. You might change the friendly name of one of these statuses, but you wouldn’t change the ID, or the general meaning of it. And you wouldn’t have a “status description maintenance” screen in your application.

A table is probably “lookup” if it is sufficiently static that there is no provision for editing it in the user interface. For instance, a list of US states, counties within a state, genders, or the like. Sure, Puerto Rico might become a state, but we’re going to call it a static list.

What do you think? Does “lookup” mean:

• static (changes break the app)
• not editable through the UI (but changes don’t break the app)
• not changed very often
• all ancillary data (everything but a few primary tables)

While reading the comments on the post Constraints are not part of the signature (which is interesting in itself,) I found this little gem in the comment section. It’s from the post author, who is a language designer at Microsoft (emphasis mine.)

Reasoning about C# design choices by pointing out that VB does it differently is not compelling. The VB language designers are building a different language and are making different design choices, in accordance with the design principles for their language. C# has always been a "complain loudly if something looks potentially incorrect" language, and VB has always been a "do your best to figure out what the user meant even if it means sometimes guessing wrong" language. Both philosophies are sensible and useful, and we offer you the choice.

That is a fundamental philosophical difference between the two languages.

This reinforces my impression that VB is designed for beginners. If you don’t know enough to tell the compiler exactly what you want, then VB will try hold your hand for you. The tradeoff is that you might not get the executable you were hoping for.

Since I’ve moved my blog from Blogger to BlogEngine, the URLs have of course changed. The old posts were .html files, so my asp.net application doesn’t process them, the and resulting 404 error falls to Brinkster (my host) to handle.

I can configure my Brinkster account to load BlogEngine’s Error404.aspx page in these cases, and the following code will successfully redirect those requests to the new BlogEngine post.

Blogger and BlogEngine both follow the convention of naming a post with the title, replacing spaces with commas.

// Jim: check for brinkster 404 redirect query string
// The query string is not name=value, it's this:
// 404;http://www.jimandkatrin.com:80/CodeBlog/2009/12/some-thoughts-on-code-reviews.html

string reg = @"^404;http://www.jimandkatrin.com:80/CodeBlog/[0-9]{4}/[0-9]{2}/(.*)\.html$";
string qs = Server.UrlDecode(Request.QueryString.ToString()); // raw query string
if (!string.IsNullOrEmpty(qs) &&
  System.Text.RegularExpressions.Regex.IsMatch(qs, reg,
    System.Text.RegularExpressions.RegexOptions.IgnoreCase))
{
  // Get the match, and construct a new URL out of it, in the BlogEngine format:
  System.Text.RegularExpressions.Match match =
  System.Text.RegularExpressions.Regex.Match(qs, reg);
  string url = string.Format("~/post/{0}.aspx", match.Groups[1]);

  Response.Redirect(url);
  Response.End();
  return;
}

// Jim: Set response code so that redirects from Brinkster 404 will actually 
// return the response code 404
Response.StatusCode = 404;
Response.Status = "404 Not Found";

The status code at the end causes the page to actually return a 404 status code, rather than a 200 OK, when Brinkster redirects to this page.

I’ve always wanted to host my own blogging software, rather than relying on Blogger, and their impending deprecation of FTP publishing got me moving on that.

After some research into various .NET blog software, I settled on BlogEngine.NET, to be hosted in my Brinkster account. I thought I would write a few notes on the transition.

The first thing to do was ensure that I could run a separate web application under the root – I have a “Pro” account with Brinkster, and setting up a new application at /codeblog/ took less than five minutes, through their online support.

Next was to download the BlogEngine source code (currently 1.6.0.0,) and open it in Visual Studio 2008; this went without a hitch. If you add it to source control, you’ll need to be sure that the files under App_Data remain writeable (I’m using the default XML file storage option.)

The next task was importing all my old posts into BlogEngine. I used Aaron Lerch's powershell script to convert from Blogger to the BlogML format. Follow the directions in the comments to get the script working, if this is your fist time messing with powershell; note that you’ll have to run powershell as an administrator. If you have two blogs under your blogger profile, they will be output as separate top-level <blog> elements to the output file; open the file with notepad and move the individual <blog> elements to separate files.

BlogML can be imported directly into BlogEngine, but first I had to replace some special characters that the powershell script didn’t handle correctly:

[’] - &amp;rsquo;  (right single quote, or apostrophe)
[‘] - &amp;lsquo;  (left single quote)
[“] - &amp;ldquo;  (left double quote)
[–] - &amp;ndash;  (dash)
[…] - &amp;hellip; (ellipsis)
[†] - &amp;rdquo;  (right double quote)

Yes, there’s a character in that last group, you just can’t see it in any text editor I tried. You can, however, select and replace it from Visual Studio.

There were a couple of disappointments in this process: the tags were not imported from my BlogML files into BlogEngine (which is a bug,) and of my old links are broken, which I knew was going to happen. I can probably fix that with a little code, though.

All in all, a very easy transition. The default template was functional, and I spent a while working on the custom one you’re looking at now. The templates are easy to tweak and edit, and there are plenty available for download.

As I’m working on the layout for this blog, I ran into this issue with clearing of DIVs in nested containers. The lower example shows that the clear:both in the child container actually clears the left-floated menu in the parent – I only wanted to clear the floated DIVs in the child, as pictured at top.

The rule here is that that clear applies to the nearest floated parent. So in the top example, clear applies within the right-floated child. If you want a region on your page to have predictable floating, it should itself be floated.

This is an important design rule for blog templates, as CSS-savvy users (like myself) are likely to use floated elements, and possibly clearing, in their posts.

The problem that I have with the upper layout is this: As the browser loads the page, it doesn’t know that the main container is going to extend below the left and right columns, until the footer loads. Until then, the container has zero height. Therefore, it doesn’t render the background color of that main container behind the columns; it shows the page background instead. Only when the footer loads, does the main container extend to its proper height and show its background over the page background. This can lead to annoying flashing of background colors as the page loads and renders.

Update:

I found a solution to the render/flashing problem here. Basically, we use CSS to append a clearing element to the container; since this applies when the container is created, it will expand with its floated contents immediately, rather than staying collapsed until the footer loads. The CSS looks like this:

/* clearfix magic */
/* to prevent background color from showing behind post during rendering */
div.clearfix:after {
content: ".";
display: block;
clear: both;
visibility: hidden;
line-height: 0;
height: 0;
background-color: #454545;
}

div.clearfix {
display: inline-block;
}

html[xmlns] .clearfix {
display: block;
}