Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

What we gain when IE6 finally dies

IE6 is on life support. The latest update I could find says IE6 had only about 20% of the market as of February.

I've mostly ignored IE7 up to this point, because as a corporate developer I have remained bound by all of the limitations of IE6. But since IE6's demise seems eminent I decided to do a quick review of what we'll gain when it finally bites the big one.

  1. Alpha channel PNG support(I've been avoiding transparent PNGs until now because the IE6 work around was such a pain)
  2. :hover on all elements not just on anchor tags (Woohoo! no more rapping DIVs and images in anchors)
  3. Width and Height Min/Max supported (is it Christmas?)
  4. CSS2: first-child, adjacent, and child selectors
  5. CSS3: attribute selectors: prefix, suffix, substring and the general sibling selector
  6. About a million bug fixes....
For full details I highly recommend this August 2006 IE Blog post about IE7 and you may also want to read this February 2009 one about IE8 to see where we're headed.

The future of computers is in your pocket

The future of computers is in your pocket. It's currently known as a cell phone, but I don't think that moniker will stick around very long.

I imagine that some time within the next 8 to 15 years things will be wildly different.

Picture this:

You get a new job. On the first day you are given your company computer which you promptly slip into your pocket. When you get to your desk you dock your computer next to your monitors and log in to the network.

That night you decide to do a little extra work from home. You take your work computer and your personal computer (which was in your other pocket) and slip them into a docking station next to your television. Working from your recliner with a wireless keyboard and mouse you toggle between your the two computers so you can get a bit of work done and catch up on your personal emails. A football game is on in the upper right hand corner of the screen and you quickly switch to it to catch the instant replay of your team scoring a touch down.

Unfortunately for you your new job requires a bit of travel. On one of your many business trips you decide to slip into a coffee shop to have lunch and get some work done. You pull out your laptop, which is just a cheep accessory with no real processing power. It's a super thin keyboard and screen paired with some sort of wireless technology to allow input and output to be exchanged remotely with your computer (which of course remains comfortably in your pocket).

This is the future of computing. I probably have the timing off and I think there'll be parts where the technology will far exceed my expectations, but I'm pretty sure I'm right on this one.

Only time will tell.

Update Panel, Partial Postback and Javascript

OK, so here's the problem. I have an update panel and after it refreshes I need to run JavaScript to initialize tabs within the panel based on their state before the refresh (partial postback). I tried getting the onload event of an element within the panel to fire and explored a few other options, but nothing I did was successful.

It's at this point I need to send out a big thank you to David Ward at Encosia.com for documenting a simple solution to triggering JavaScript on partial postback client-side initialization. It turns out that Asp.net wires up any JavaScript method named pageLoad() to the Application.PageLoad event so it not only gets called on the initial page load but also on any partial postback. With this fact in hand getting my JavaScript to fire was a snap.

This is my final code:

pageLoad = function()
{
  if(this.isPostBack != true)
  {
    cr.initPage();
    this.isPostBack = true;
  }
  else
  {
    cr.initTabs();     
  }
};

You'll notice that I initially test if this.isPostBack != true, but since it doesn't exist yet it can't be true. This allows the first if block to run, initialize the page and set this.isPostBack to true. All future times the pageLoad function is called will be in post backs. At that point this.isPostBack will return true because my previous setting of this value was preserved through the partial post back and my tab initialization will run.

Again thanks to David for pointing me in the right direction.

Firefox and Blogger conspire against me

I recently discovered that my post on image layering was not displaying correctly after a minor edit to the post, despite the fact that I had tested the post beforehand in IE6, IE7, Firefox, Chrome, and Safari. On examining the post I was surprised to find that the markup had been changed.

The first problem I found was that my image urls had been altered (slashes and http stripped from the CSS... just weird). I had to fight to get blogger to accept these, but eventually they went through. I also just found that IE6 was still having problems, so I've made yet more changes to fix that.

After a bit of experimentation I found source of the IE6 problem (though the url problems still remain a mystery). When you click the blogger Preview link to preview your post, Firefox strips the markup of all IE specific CSS and injects additional Firefox specific CSS. When you click Hide Preview, blogger apparently pull this updated markup back into the HTML Editing textbox. Since previewing is normally the last thing I do after I edit a post I didn't notice the markup changes. Of course everything looked fine when I viewed the edited post in Firefox, because Firefox had optimized it.

So if you happened to have viewed my image layering post and my examples looked really bad please check them out again. I'm sorry for the inconvenience.

The benefits of ergonomic keyboards and mice

I'm stunned by how many companies now give developers two large flat screen monitors by default but scoff at the idea of getting them ergonomic keyboards and mice. The cost is a fraction of that of a single monitor and can prevent injuries (downtime) to people who are critical to company operations. I imagine it's because dual monitors have been widely praised for providing a productivity boost to developers (and rightly so), but ergonomic keyboards and mice have not been; health concerns are just a tougher sell.

The surprising thing about ergonomic keyboards and mice is that they tend to have productivity features built into them, including programmable keys that can be customized per application. The added productivity from this, even if you consider it to be rather minimal, adds up to to more than enough on a programmers salary over a year to justify it's purchase. Unfortunately these gains are not yet being shouted from the rooftops, so it may be sometime before companies come around.

I was looking forward to posting about my weekend acquisition of a Microsoft Natural Ergonomic Keyboard 4000, one of the most well designed and pleasing devices I've ever used (and it has tons of programmable features to boot). So I was surprised and little peeve yesterday morning to find that Jeff Atwood over at Coding Horror stole my thunder by touting his re-purchase of the Keyboard 4000. My only consolation is that at least he didn't purchase a Logitech Marble® Mouse, my second favorite piece of data-entry paraphernalia, so I can independently tout it's virtues.

The Marble® Mouse is a trackball and its symmetrical design means that it can just as easily be used by you lefties out there. It has two additional programmable buttons that can be set to nearly any function you like. While it may take a little adjustment for those of you who haven't used a trackball before, I think it's far superior to any other mouse I've used; even more so if you have limited desk space, as I do.

I realize that my preference for these particular ergonomic devices is to some degree a matter of taste but, what ever device you choose, I would encourage you to to start using ergonomic devices as early in your career as possible to ward off future problems. And if you're already having problems... QUIT PUTTING IT OFF! I don't know why but we developers, myself especially, seem to ignore common sense measure at taking care of ourselves. As the minor health annoyances of middle age and the detrimental effects of a sedentary carreer in front of a computer start to set in, I'm starting to take things like this more seriously.