JavaScript provides no good way to check if a variable exists.  If you try to use one that doesn't, you get a big fat error.  I've seen some people use:

if (myVar == undefined)

But this only works if the variable has been declared, but wasn't set to a value.  Sometimes, you don't know if the variable was even declared.

Here's some code that solves that: 

try {
      if (myVar) {}
} catch (err) {
      var myVar = "";
}

Update: I'm getting reports that this has been fixed in Java 1.6 (aka Java 6).  So, I tested this with the latest Java 1.6 32-bit in Ubuntu Edgy, and apps seem to be working fine under Beryl.  So, you may not need to go to all the trouble below.  The latest Java 1.6 for AMD64 on Ubuntu Edgy, however, still doesn't work for me under Beryl.

I recently built an AMD 64-bit dual core machine, and installed Ubuntu Edgy for x86-64 on it.  One thing I found (and had read elsewhere) is that 64-bit Eclipse is buggy.  It hangs and dies usually within 30 minutes, and sometimes on a few minutes.  And I found the performance improvements to be hardly noticable, so not worth the hassle of frequent crashes.

My solution was to switch back to the 32 bit Eclipse.  Not hard, but not dirt simple.  First install the 32-bit JVM ia32-sun-java5-bin.

Anyone who runs in computer-technology circles has seen the "my favorite app" zealots.  They preach of how you must use their favorite application.  They claim that you must be stupid if you use the competing application.  There are Gnome/KDE/*box/Enlightenment/etc. zealots, Linux/BSD/Mac OS zealots, XMMS/BMP/Amarok/etc. zealots, Java/.NET/PHP/Python zealots, and perhaps the oldest of them all, vi and emacs zealots. 

I just read a post on Debashish Chakrabarty's blog titled "Primer: Difference between javac and JIT". It contains a very good explanation of what Just In Time (JIT) compilation is and how it relates to HotSpot JVMs. HotSpot JVMs identify sections of code that are worth taking the time to compile from bytecode to machine code. These sections of code are referred to as hotspots.

I've noticed many web authors puting their Cascading Style Sheets straight into the header of a page. Folks, that's bad! There are many benefits to moving style data out of the body of your html and into CSS, and one of them gets lost when the CSS is placed in the header.

Today I was looking around java.net, the new Java community site created by Sun. According to a post by Karsten Lentzch on Java Desktop:

JGoodies is excited to announce the open sourcing of two of its projects: Looks and Forms. Read more on the JGoodies project page on java.net

You just have to love a developer with a dry sense of humor. Someone with some extra time created a project over at SourceForge called Denoser. This is the project's official description:

This may seem like a trivial entry to some, but I had a terrible time figuring out how to get the Jetty integrated JBoss distribution to look like your standard webserver. It took me so much time, I promised myself I would publish directions to make it easier for others.

A) JBoss-Jetty runs on port 80
B) JBoss-Jetty has a root context (the base application for the website, such as http://dmartin.org).

A) wasn't hard to figure out.

Doing some blog exploring today, I was brought to the sad realization that I'm a FontBitch. I swear it wasn't intentional, though I admit I usually use styles in true font point sizes, "font-size: 10pt". Now I know why that's a bad thing. I'll put it somewhere (at the bottom) on my list of my 1000 useless things I'll never get around to fixing.