Si ya estás utilizando la versión 2.0 de Firefox, te habras fijado (y sufrido) que las pestañas tienen el botón de cierre sobre ellas mismas, en vez de haber un único botón a la derecha del todo, como en versiones anteriores.
Esto puede llevar a que cierres sin querer una pestaña, cuando lo que querías era seleccionarla, y puede resultar bastante molesto. Además de que si quieres cerrar muchas ventanas seguidas (a veces pasa, sobre todo cuando tienes incontinencia de clicks y abres muchas pestañas), tienes que ir una,, seleccionándolas y cerrandolas buscando su botón, en vez de pulsar el mismo botón de cerrar muchas veces.
Todo esto se arregla haciendo lo siguiente:

1. Vamos a la ventana de configuración tecleando en la url about:config
2. Buscamos el campo llamado browser.tabs.closeButtons
3. Hacemos doble click para cambiarlo y ponemos 3

Y ya tenemos el botón de cerrar como en las versiones anteriores: solo uno y en el mismo sitio.

Y aún así, si cierras una pestaña sin querer (o varias), puedes “deshacer” el cierre usando esta combinacion de teclas:CTRL + MAYUS + T

Vía Mdug

ACTUALIZACIÓN:
No hace falta ir a la derecha del todo para cerrar una ventana, siempre puedes utilizar la rueda central del ratón como click en la pestaña y se cerrará la ventana. De hecho, yo es la forma que uso para cerrar pestañas (y CTRL+W). El botón de la derecha del todo lo uso para cerrar muchas pestañas seguidas.

Esa es, ni mas ni menos, la frase clave que había que teclear en el antiguo juego “Zipi y Zape” para resolver uno de los puzzles sin resolver más antiguos que existen.

Para el que no sepa de lo que estoy hablando, Zipi y Zape es una aventura conversacional clásica de los 80. Un juego de 8 bits de hace muchos años el cual tenía la fama de ser irresoluble por un bug. No se podía pasar una parte del juego y nadie sabía como hasta hace casi unos días.
Y en La Linea Dura, además de darnos la solución, su autor nos demuestra como ha conseguido descifrar este enigma extrayendo el código de la aventura a partir de un snapshot en memoria y algunos trucos más de Spectrum para buscar la frase apropiada.
Simplemente GENIAL.

El primer mensaje original del anuncio de esta solución aquí

A veces podemos querer tener la traza de una Exception para pintarla en nuestro JSP de error con un formato bonito o enviarla por correo. El método siguiente nos devuelve un String con el resultado del printStackTrace() de un objeto Throwable (el padre de Exception y Error):

public String getStackTrace(Throwable e) {
        StringWriter stringWriter = new StringWriter();
        e.printStackTrace(new PrintWriter(stringWriter));
        return stringWriter.toString();
}

Si trabajas programando, seguramente hayas oido más de una de estas frases.

• Si compila, funciona
• Si compila, el codigo es correcto.
• Si ejecuta, es que no tiene bugs
• Si no los bugs no aparecen inmediatamente, es perfecto
• Si un bug no aparece, es que no existe
• Si parece que funciona, entonces funciona
• Hacer las cosas bien es facil. Para evitar los errores solo hace falta un poco de concentracion
• A menor tamaño de codigo, mas velocidad
• Es obvio como optimizar un programa
• Los programadores no comenten fallos
• Los errores en tiempo de ejecucion (runtime error) nunca ocurren
• Los usuarios no cometen fallos
• Yo no cometo fallos
• Los errores de cualquier tipo son raros
• La gestion de errores para la version 2
• Es correcto que se cuelgue si los datos de entrada son malos
• Es correcto que devuelva datos malos por si los datos de entrada son malos
• La portabilidad no es útil
• Lo que importa es el tamaño de la lista de features (caracteristicas)
• La velocidad es buena, pero las features (caracteristicas) son mejor
• La lentitud se arregla ampliando hardware
• Cuanto mas grande es un programa, mejor es
• Los cambios aleatorios en el programa arreglan los bugs.
• Para probar solo hace falta muy poco tiempo
• Encontrar fallos es facil, arreglarlos es trivial
• Los bugs arreglados no necesitan ser probados
• Los cambios triviales no necesitan ser probados
• La primera idea, aproximacion o version es siempre la mejor
• El codigo es autoexplicativo, no hace falta comentarlo.
• Los comentarios estan hechos por y para otra gente distinta del autor.
• Las features sin documentar son utiles y divertidas
• Siempre se puede arreglar para la siguiente version
• Usuarios sorprendido, usuario feliz
• La mejor manera de depurar es en la demostracion con el cliente

La versión original está aquí. La traducción la he hecho yo mismo, pido disculpas si no está del todo bien (o si la cosa ha perdido gracia con respecto a la versión inglesa)

Si en tu codigo tienes cosas como ésta:

public class Constants {
    public static final Set cosas = new HashSet();

    static {
          cosas.add("foo");
          cosas.add("bar");
    }
}

Puede que sea mucho más comodo hacerlo así:

public interface Constants {
    public static final Set cosas =
         new HashSet(Arrays.asList(new String[] {"foo","bar","tal"} ));

    public static final List cosas =
         new HashSet(Arrays.asList(new String[] {"foo","bar","tal"} ));
}
public class implements Constants {
    //...
}

Mejor, ¿no? Para los Map no hay manera, hay que hacerlo a mano…