I found it very ironic the way the title of my last post was displayed after being imported into Facebook:

Here is a message I got after logging into a website recently:

** NOTE ** Using a colon (“:”) in your password can create problems when logging in to Banner Self Service. If your password includes a colon, please change it using the PWManager link below.

Protip: If you are designing any kind of login/authentication system and you find that you need to give users a warning similar to this, you are doing something wrong.

On a much more nitpicky side note, why not just make “PWManager” or “using the PWManager” link to PWManager?  To their credit, at least they didn’t say “by clicking the PWManager link below.”

I’ve come up with a very simple solution to the problem of browser-cached CSS files.  What I mean by this is: when you update the CSS which manages your website’s presentation, it will take a while before some visitors actually see those changes.  The reason, of course, is that browsers (this is at least true of IE and Firefox) will cache CSS files pretty aggressively, without checking very often to see if they have been updated.  Usually refreshing the page will solve this, but most visitors aren’t going to care enough to do this.  Meanwhile, your site will look pretty broken to them (especially if you’ve done something like styled a list so that it looks like a horizontal toolbar instead of a bulleted list, for example).

So here’s the very simple solution.  Add the following rule to your root .htaccess file:

     RewriteRule ^(.*)\.[\d]\.css$ $1.css [L]

I’m assuming that you have a common include file or template or something which prints things like the page header.  If so, whenever you update your CSS file (say, style.css), you update the link tag in your header to use style.0.css.  This will look to the browser like it is a different file from style.css, so it will download it again.  But Apache is really just loading the same CSS file through the magic of URL rewriting—you’re just ensuring that the user picks up your recent changes.  You can repeat the process the next time you tweak your CSS, just change the header to style.1.css and so on.

No, and I don’t care.

Nearly two months ago, I joined Facebook.  I had low expectations, despite the fact that a few people whose opinions I value told me the same things I’m about to tell you.  I have to say, as a whole, Facebook doesn’t really suck.  I guess I was expecting something more like MySpace, which just kind of looks like the Internet ate too many gifs and had to throw them up as partially-digested ads.  Or something like that.  I probably stretched that analogy too far there.  Whatever.  The point is Facebook doesn’t suck, and it’s actually kind of fun, even for an antisocial computer geek like myself.

While scanning through my junk mail folder in Gmail, I noticed a new spam tactic: directly insulting the reader.

<img class=”snapshot” src=”/files/for_blog/20080609_insulting_spam.png” title=”Snapshot of my spam folder, with subject reading “You look really stupid kip.robinson”” alt=”Snapshot of my spam folder, with subject reading “You look really stupid kip.robinson”” />

I’m curious if this is effective.  I find it hard to believe that anyone would ever read mail that is obviously spam nowadays, but these people must be making money somehow or they’d stop sending this stuff.  My guess is that anything which stands out is likely to be effective in piquing readers’ curiosity, much like the “I love you” e-mail virus from several years ago.  But only if other spammers don’t copy the tactic.

Do programmers still need to understand pointers in this day and age?  Is Java a good programming language?  Why is there something as opposed to nothing?

Please do not indulge in heated debate pertaining to any of the above unanswerable philosophical questions.  Instead, just let me show you what can happen when someone has to program in Java without understanding two things about the Java language: 1) all parameters are always passed by value; 2) objects are basically pointers (whose address can only be modified by assignment).  Without this knowledge, you might write code like this*:

           //ABC-defect#123456 - SetChildren update currSel so we need to take bakup of
               //currSel so that after returning we can set it back to original currSel
          TreeNode tmpCurrSel = currSel;
      int result = setChildren(currSel,fullTree,0,tmpLevels);
         if (tmpCurrSel != null)
               currSel=tempCurrentSelection; //ABC-defect#123456

Hint: it does not work as the developer expected it to (and obviously he never tested it after he coded it).

* Code has been anonymized, but indentation and grammar is preserved for EnhancedRealism™.

A few weeks ago I installed Firefox 3 Beta onto my work laptop, in order to test if two add-ins I wrote would need any tweaking to work.  (These add-ins are simple search bars for people in my company to use to search our source code and our bug-tracking database.)  They worked fine, once I jumped through the necessary hoops to convince Firefox that they weren’t viruses.  But that’s irrelevant; this post is about two small “it’s about friggin time” improvements in Firefox 3.  You can read about the big changes elsewhere.

The first of these changes is the way Firefox handles hyphens in text wrapping.  After a long period of bickering, they finally decided that Firefox (like every other piece of software which displays text) can insert a line break after a hyphen character.  This is something that is particularly annoying to me, since I sometimes use long, hyphenated phrases.  (I’m sure there is a proper name for such a phrase, but I don’t know it.  I guess that’s what I get for not being an English professor.)

Take for example this post from a few weeks ago in, as viewed in FF2 and FF3:

See how FF2 treats the long line as a single word, rather than breaking the words on hyphens?  In Firefox 3 this has been corrected, which I think is super.

The other small thing is that tooltip text (usually from an object’s “title” attribute) is no longer truncated.  This is mainly a nuisance to me on webcomics xkcd and Dinosaur Comics, where the tooltip text is usually kind of a second punchline.  To demonstrate, here is a screenshot from a recent xkcd comic:

Much better in Firefox 3.  These two improvements (and the new address bar features) make me excited to use Firefox 3.  Of course, I won’t switch to it full-time until the final release, since most of my favorite add-ons don’t support FF3 yet.

In case no one ever told you, Monster cables are a waste of money.  It turns out, a coat hanger is just as effective as Monster Cable at transferring an audio signal.

I knew it would happen eventually.  I put in some code that broke our software, and it wasn’t discovered until nearly a month later, on the day the final build was scheduled.  This meant that the final build had to be delayed for a few days, which is kind of a big deal because it can affect ship date.  So lots of e-mails were circulated which featured my name—often in a red, boldface font—in various lists of actions.

Posted below is a paraphrased version of the code in question.  I’ve renamed or taken out anything that might refer to our internal codebase, and I’ve simplified a little, but not to the point that I look like a complete idiot for missing this.  The QueryInterface() and Release() stuff might look a little weird if you’re not familiar with COM+.  Or all of this will look weird if you’re not a programmer.  But odds are you’re about to stop reading if you aren’t a programmer.

LIST(IUnknown) listObjs;
Session->GetModifiedObjects(listObjs);

const int nbObjs = listObjs.Size();

if (nbObjs > 0)
{
  ObjectID** listObjIds = new ObjectID*[nbObjs];
  for (int i = 1; i <= nbObjs; i++)
  {
     ObjectID* pObjId = NULL;
     
     IUnknown* pUnknown = listObjs[i];
     IPart* pPart = NULL;
     if (pUnknown != NULL)
     {
       RC = pUnknown->QueryInterface(IID_IPart, (void **) &pPart);
       pUnknown->Release(); pUnknown = NULL;
     }
     if (SUCCEEDED(RC) && pPart != NULL)
     {
       RC = pPart->get_ObjectID(pObjId);
       pPart->Release(); pPart = NULL;
     }
     
     listObjIds[i] = pObjId;
  }
  ...
  //process listObjIds
  ...
  for (int i = 1; i <= nbObjs; i++)
  {
     if (listObjIds[i] != NULL) { delete listObjIds[i];  listObjIds[i] = NULL; }
  }
  delete [] listObjIds;  listObjIds = NULL;
}

For those of you still with me, maybe you already see the problem.  The LIST() macro in our infrastructure behaves pretty similarly to a Vector in Java: it will resize itself dynamically, check array bounds, and automatically free memory when it is destroyed.  However, because this was written long ago by guys with a Fortran background, the items in the list start at 1, whereas a C++ array starts at 0.  Also, it only works with components implementing IUnknown; plain-old-C++ objects must be handled with plain-old-C++ arrays.  In the code above, this meant I could not declare listObjIds as an object of type LIST(ObjectID*).  So I had a LIST(IUnknown) and an array of ObjectID*s, but I treated both as LISTs!  In fact, I have gotten so used to using LISTs in C++ that I completely forgot that listObjIds was an array (I guess a better variable name would have helped too).

The line listObjIds[i] = pObjId; should instead be written listObjIds[i-1] = pObjId;, since i loops from 1 to n, rather than 0 to n-1.  (Note that the line IUnknown* pUnknown = listObjs[i]; is still correct.)  So I was writing beyond the memory allocated to the listObjIds array.  And amazingly, it worked just fine in all my testing.  Most of the time, the next sizeof(void*) bytes on the heap aren’t going to belong to anyone.  But there is a chance that they are used for some other variable, whose value you would be overwriting.  This is especially more likely if memory has become very fragmented.

We run unit tests on all four operating systems we support, but only one operating system (HP-UX) was affected by this.  And since we don’t currently have any customers using that OS, it was a while before anyone looked at the traces very closely.  Unfortunately, it happens that this code was implemented in a listener that is called every single time the user saves.  So when it was discovered, it was something that had to be fixed before the final build.  We could have delivered it as a patch, but some customers are reluctant to deploy patches because that can mean shutting down production for a few hours.  Plus it doesn’t instill confidence to say we shipped broken code.  So delaying the final build for a day or two was the best option.

The worst part of it all is that it happened just before year-end performance reviews.  Doh!