I was updating an old app to use SQL on a new SQL Server database rather than an older Access database. As any database programmer is aware, there are irritating inconsistencies between Access SQL and SQL Server's T-SQL, such as absence of the IIF() and Trim() functions in T-SQL.

So I was going through the SQL and making these changes. I came across a very ugly IIF() function similar to this:

Take that statement and add even more boolean fields. Clearly, the intent was to have a calculated field that had a friendly name based on which boolean field was true.

So, how can this be easily converted into a CASE statement? As it stands, CASE statements are actually more verbose than the IIF() function, and the IIF() function above is already hard to read and verbose as it is.

A direct code conversion would be something like this:

Ugly, ugly, ugly. The cool thing about CASE that differs from IIF() is that you can attack it from the other direction. Instead of saying, "Is phLead true? Is phFax true? Is phVVM true?", you can instead say, "Okay, who's true? phLead? phFax? phVVM?" It sounds negligible, but the code is shorter and easier to read:

Ahh, much better.

After installing Windows Vista, I could not connect to my Samba fileshares. I'm running Samba v3.0.10 on CentOS v4.4.

It turns out that NTLMv2, the authentication protocol, is required by default on Windows Vista. According to the Samba Features by Release wiki page, support for NTLMv2 in Samba wasn't fully developed until Samba v3.0.21.

Running yum would be a quick way to upgrade Samba to a more recent release. For some reason, though, the repositories I'm pointing to only have v3.0.10 as the latest available update. Rather than hassling with it, I found an article that attacks the issue from the Vista end.

The article Get Vista and Samba to Work explains how to get Vista to use the older authentication protocols, like the original NTLM. After making this change, I was able to login to my shares immediately.

Basically, all you need to do is run the Local Security Policies console snapin (secpol.msc), open Local Policies --> Security Options --> Network Security: LAN Manager authentication level, and change the setting from "NTLMv2 responses only" to one of the more lenient settings, like "LM and NTLM – use NTLMV2 session security if negotiated".

This works for me because I have one, sometimes two, machines with Windows Vista connecting to my server. If you had lots of machines connecting to the server, it'd obviously be worth your time to just upgrade Samba to a version that supports NTLMv2.

Both Linux and Mac OS X have zip, gzip, and bzip2 command-line tools. What about Windows? If you're trying to do some scripting to automate some archiving or backup, and you want it to be a classic, WinZip-compatible .zip file, how can you do it?

WinZip offers a WinZip Command Line Add-on free of charge--if you already own a copy of WinZip Pro!

You shouldn't have to pay for command-line zip. And you don't have to. Enter Info-ZIP. This workgroup has been maintaining free, portable, high-quality versions of zip and unzip. They have plenty of command-line arguments like you would expect from an open source project.

So, with this project's executables in your system path, you can write up a batch file that is executed as a Windows scheduled task. Maybe something like this:

This will zip the c:data directory. Arguments: -q to do it quietly, -S to include system files, -r to recurse into subdirectories. Finally, use -i to point to a file that indicates the exact files to include, by means of a carriage return delimited list.

You can alternatively use -x to specify only which files should be excluded. Perhaps something like this:

The command-line flags are all optional, of course. This tool is certainly a must-have for the Windows scripter.

All web developers are familiar with the need to tweak their CSS so that it will look presentable in both IE and other more standards-compliant browsers. Many people have declared, some more infamously than others, that people should boycott IE, and have proceeded to develop designs that are standards-compliant but IE-unfriendly. I feel that this is foolish; IE is still the browser of choice by most non-geek web surfers, and unless you're developing in a controlled environment where you can declare the browser to be used, you really should code for any popular browser, and even then, it's just good practice to write clean code that works everywhere.

Alas, I digress. The point is that IE isn't going anywhere for now, and it is a pain sometimes to figure out how to write CSS that renders as close to identical as possible between IE and other browsers like Firefox. There are several sites out there that endeavor to explain the IE bugs and, when possible, provide workarounds.

Sure, I could just alter the CSS to look right in IE, but if I'm not careful, that "fix" then breaks the code in Firefox! So we've come up with hacks to have CSS that other browsers will see but IE ignores. I don't know about you, but I'm tired of trying to understand and remember these tricks for satiating IE.

Welcome to conditional comments in IE. This is yet another IE-specific feature that we can actually use to our advantage to level the playing field.

Conditional comments are just what they sound like: HTML comments. But these comments are coded in such a way that effectively have a conditional statement in them, and any HTML output within the comments will only be included (by IE) if the condition is true. Here is an example.

As you can see, any non-IE browser will just ignore all the content, since it's really one large comment. But IE recognizes the conditional logic inside the comment and renders the content accordingly.

Here's an example. This box will have a message if you're on IE, and it will be blank if you're in any other browser:

If you wanted, you could use this technique to inject HTML elements specifically for IE.

Yeah. If you want a maintenance nightmare. Do not sprinkle conditional comments in your code.

Rather than having a CSS file littered with IE fixes (or just accepting the variances between IE and Firefox), I would much rather have a single "clean" stylesheet file that is then augmented by an IE-only stylesheet, loaded by IE and ignored by all other browsers via the conditional comments feature.

So, perhaps you might have some code like this in your header:

There is still a very real danger here. You don't want to fall into the tendency to write intolerant CSS that needs a lot of "cleanup" to look good in both browsers. Work hard to make your CSS as compatible as possible, and leave the ie.css file exclusively for the rare cases where you could not resolve an inconsistency in IE. When you're done, your ie.css file should be really small, if you require it at all.

Having said that, however, I think this is a graceful solution. You don't sacrifice the consistency of your HTML nor your CSS, and your only extra work is the tweaking done in your IE stylesheet. Other solutions like Targeting IE Using Conditional Comments and Just One Stylesheet over at PositionIsEverything.net recommend adding an IE-specific div tag around your content, which would enable you to have a single stylesheet and to not just include IE-specific styles but also exclude certain styles from IE. Unless you have some CSS that you just can't tweak for IE and you have to exclude it, I definitely prefer the simpler approach of just including a secondary, corrective stylesheet and leaving the HTML alone. But that's just the purist in me.