In web development, the first 90% of development time is devoted to all the other browsers, and another 90% of the time is devoted to Internet Explorer. Thanks to Firebug in Firefox and Safari’s excellent developer tools, I’ve given up hideous “alert-debugging” in favor of logging informative messages to the console with console.log('a message'). You can even get a little fancy with printf-style formatted output, e.g., console.log("var i: %s",i).

But then development moves to IE, and I get bitten by the forgotten console.log() left in the code somewhere. Presumably, IE9 will have some kind of console, but we’ll be testing back to IE6 for years, so this is a problem that’s not going away.

I’ve seen a lot of “solutions” that create new jQuery functions–and we’re all using jQuery now anyway, right?–like $.log() and then you’re supposed to stop using console.log() in favor of this new function.

But I’m a stubborn old man, and my arthritic old fingers won’t soon forget the keystrokes, so I find this approach a little unworkable. What I really want is to leave console.log() alone if it’s available, and if not, drop a DIV into the page to send output to. So I used the code from the above link as a point of departure, and worked it into something that does what I want:

log: function(msg) {
$("body").append("<div style=\"width:600px;color:#fff;background-color:#666;\">" + msg + "</div>");
return true;

// create object and define method if not present
if ( !window.console )
window.console = new Object;
window.console.log = $.log;

The strategy is, define a jQuery function $.log() (or jQuery.log() if you prefer) and then assign it to console.log() if it doesn’t already exist. The last block is the key: create an object window.console and assign $.log to a method in the object.

Now I can continue leaving console.log() in my code to debug. If window.console exists, $.log() is defined but never used; if window.console does not exist, it is created and passed $.log and uses that.

Now I just have to remember to include a file debug.js which contains this mess, but to me that’s easier than learning a whole new function which also requires the extra code to define it anyway.

bc Extensions

More often than not, if I have to do any calculations from my laptop, I eschew the very fine GUI application PCalc in favor of bc on the command line. I also like to use the extended version, bc -l to get decimal places in my result.

Like most bc enthusiasts, I have this aliased in my .bash_profile file like so:

alias bc='bc -l'

But if you’re a bc nerd, this probably isn’t enough; you also want to pre-define functions and have a bunch of scientific constants, too. There’s a pretty standard extensions.bc file out there, and you can get it from the straight from the open-source project: first a buncha functions, then the scientific constants.

The usual way is to include these when you run bc, so your alias in .bash_profile becomes

alias bc='bc -l /PATH_TO/extensions.bc /PATH_TO/scientific_constants.bc'

After a while, I know I’ll forget where my bc extensions files are, so I include a message in my alias:

echo "Using bc -l with extensions in /PATH_TO/"

So my alias is

alias bc='echo "Using bc -l with extensions in /PATH_TO/";bc -l /PATH_TO/extensions.bc /PATH_TO/scientific_constants.bc'

Now every time I run bc, I see

Using bc -l with extensions in /PATH_TO/
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.

And that way I can remember why it works just the way I want it to.

Cats: hack,unix

One Two Three

At a high level, all software development–perhaps all invention–breaks down into three steps:

  1. Build it the way you thought it should work
  2. Do it from scratch the way you should have done it to begin with, as you learned during the previous step
  3. Optimize step 2 from scratch so you can actually ship it.

And of course, loop on steps 2 and 3 from then on.

Sometimes you’ve done step 1 so often, you hit the ground running with step 2, but not if it’s a new technology. And I can’t say I’ve always gone through all three steps for every project, but I’ve always wished I could.

Form Field Backgrounds

At the Day Job I was called upon to make form fields with rounded corners. There’s a lot of approaches out there, but most of them are a bit too complex for my liking. Generally, it’s some variation on the old-tymey technique of putting something in the center of a 3×3 table, but with DIVs or what-have-you.

Forget that, I want something simple, just a bit of CSS I can tack onto text input objects. The simple approach seemed to work:

   width: 90px;
   height: 26px;
   background: url(/images/text-field.png)

…at first. It turns out Internet Explorer anchors the background image to the text field, and if you type beyond the border, the image scrolls off to the left as you type.

Well, that’s okay, you can just anchor the background with “background-attachment: fixed;” like so:

   width: 90px;
   height: 26px;
   background: url(/images/text-field.png)
     fixed no-repeat;

Ah, but there’s a slight problem now: Firefox and Safari respond to this new attribute by not showing the background image at all. I have to say, and this could be a first for me, my opinion is that IE gets this one right. Scrolling makes sense, and a “fixed” background is the right solution.

But such is the life of a web developer, making things work the way they are, not the way they ought to be. So, alas, I left the “fixed” attribute out of the CSS–works for Safari and Firefox–and used jQuery’s “document ready” function for IE:

if ( $.browser.msie )

It’s a little weak, I know, but sometimes quick and dirty is the best solution. Besides, without JavaScript, the rest of the site will fail much worse than this form field.