I love being able to write something like this:

perl -F: -ane '$hash{$F[0]}++;} for my $key (keys %hash) { print "$key: $hash{$key}\n"; } {' <file>

Actual code from my company's codebase:

     $playlist{$key}[4] = $line[4];
     $playlist{$key}[5] = $line[5];
     $playlist{$key}[6] = $line[6];
     $playlist{$key}[7] = $line[7];
     $playlist{$key}[8] = $line[8];
     $playlist{$key}[9] = $line[9];
     $playlist{$key}[10] = $line[10];
     $playlist{$key}[11] = $line[11];
     $playlist{$key}[12] = $line[12];

At a couple of my old positions, various people of varying levels of education always kept coming up with the hare-brained idea of making XML the defacto format for anything, from internal data files to configuration files. Granted, there is an advantage to this--there are XML parsers either built-in or readily available to just about every programming language in common use nowadays. Not that said people ever thought about using those parsers--they were just on the whole XML bandwagon from reading hypey trade mags.

The author of Thinking in Java, Bruce Eckel, in his article "Simplifying XML Manipulation," wrote the best description of why I personally think that XML is a poor choice for internal data files and just fucking stupid for config files:

My initial strategy for XML was to recognize it for what it is -- a platform independent way to move data from one place to another -- and then, as much as possible, to ignore it and assume that I would only have to actually look at XML when I was debugging something...

Fedex and the Post Office (and UPS apparently also works this way) -- [use] something that's almost XML-RPC, but it's not, and you're expected to assemble your XML by hand and then use HTTP to send it to the server, then unbundle the XML that comes back...

The point being that here's a case where the XML should have been invisible, but you have to mess with it by hand.

Apparently everything written about Windows 2000 doesn't apply to Windows XP when it comes to synchronizing time with NTP. "net time /set" does not work, even after the appropriate "net time /setsntp:server" command. Windows XP requires the following:

C:\>w32tm /resync

There is no longer a '-once' option to the w32tm program, and you shouldn't need to stop and restart the w32time service for this to take affect.

C:\>net time /set
Could not locate a time-server.

More help is available by typing NET HELPMSG 3912.

C:\>net helpmsg 3912

Could not locate a time-server.

C:\>

Microsoft, I hate you with every fiber of my being.

The following line of code:

for tmpfile in os.listdir('/some/empty/directory'):

Throws the following error when run on Windows CE:

Traceback (innermost last):
  File "\Program Files\Python\Lib\myscript.py", line 148, in ?
    for tmpfile in os.listdir('/some/empty/directory/'):
ValueError: Invalid path

Go figure.

Looking at the following code:

if ($foo == 1) {
  echo "Foo is 1";
}
elseif ($foo == 0) {
  echo "Foo is 0";
}

If $foo is not defined (as in the case of, say, an unposted $_POST variable), $foo == 0 evaluates as true.

All null values equal 0 apparently, forcing any specific zero-check to look as follows:

if ($foo == 1) {
  echo "Foo is 1";
}
elseif (($foo == 0) && (is_numeric($foo))) {
  echo "Foo is 0";
}

Sometimes I hate this language.

count (PHP 3, PHP 4 , PHP 5)
count -- Count elements in a variable
Description
int count ( mixed var [, int mode])

Returns the number of elements in var, which is typically an array (since anything else will have one element).

If var is not an array, 1 will be returned (exception: count(NULL) equals 0).

Except, for some reason, count($var) where $var == NULL returns 1.

WTF?

"item" is apparently a reserved word in Internet Explorer's Javascript parser. Go figure.

Because making that assbag of a device work faster and/or better means one less headache a day.

http://www.rainer-keuchel.de/software.html