Si estás utilizando la última versión de Ubuntu (9.10 Karmic Koala) y la última versión de Eclipse (descargada de su propia página web, no la que se obtiene de los repositorios de Ubuntu), es posible que des con un error en el que algunos botones de determinados menús no reaccionan a las pulsaciones del ratón como deberían (aunque sí a las combinaciones de teclas Alt-letra, por ejemplo). Parece estar debido a algunos “trucos” gráficos que hace eclipse para saltarse algunas cosas del gdk, y para solucionarlo lo que hay que hacer es lanzar eclipse desde un script como este:

#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/opt/eclipse-3.5/eclipse

Cambiando el path último por aquél en el que resida la instalación de Eclipse, claro.

Solución encontrada en norio.be. Otra opción es utilizar la versión de Eclipse del repositorio de Ubuntu, con esa versión el error no aparece.

Facebook Lite es un rapido, mas simple camino para manteenerte en contacto con tus amigos. Si te gusta, tu puedes elegir utilizarlo en uno de el Facebook regular yendo a el menù Herrmientas. Nosotros aun tenemos trabajo que hacer antes de que este completo, pero nosotros apreciariamos obtener tu hoja de vuelta en lo que tenemos construido hasta ahora.

Creo que sí, aún tienen trabajo que hacer antes de que esté completo.

En un momento de portentosa inspiración, se me ha ocurrido iniciar una serie de nuevos posts sobre bugs existentes en algunos sistemas de software que, parece, nunca se van a solucionar. Empiezo con uno que acabo de ver (otra vez) mientras trabajaba en la oficina con Visual Studio 2008:

Bug en Visual Studio 2008 (el icono corrupto)

Sí, obviamente es una tontería que sólo afecta a un icono cuya imagen parece corromperse, y con seleccionar la pestaña se soluciona… pero siendo algo visual no acabo de comprender cómo nadie lo ha visto antes.

neverbyte.net actualizado a WordPress 2.6.1. Espero que el bug que tenía con los nombres de tags se haya solucionado… porque tuve que arreglarlo “a mano” y no me apetece volver a buscar la solución.

Pues no, no está solucionado aún y he tenido que volver a parchear el archivo wp-includes/taxonomy.php (cuando además ahora es ligeramente distinto y aplicar el parche no es tan directo). No tengo usuario en el trac de WordPress para anotar que eso sigue pendiente y que es importante.

Comprobar condiciones de las que ya sabes el resultado. Ejemplo: comprobar que al convertir algo a string el resultado es el que nos interesa y posteriormente comprobar que ese algo no era null. Si hubiese sido null la conversión a string habría sido algo más problemática, ¿no?

if (!(Session["blabla"].ToString() == ""))
    if (!(Session["blabla"] == null))
        [...]

Hacer la comprobación en el orden inverso habría tenido un cierto sentido (aunque en este ejemplo concreto nunca iban a ser null). Un día de estos me voy a cortar las venas si sigo viendo estas cosas. ¿Y lo bonito que es el símbolo != que es más dificil de confundir? ¿Dónde ha quedado?

Estoy actualizando la documentación de un proyecto. Actualizando la documentación para que ahora sí se ajuste al código hecho, porque el código pone una cosa y la documentación otra… en fin. El caso es que aprovecho para leerla entera a ver si encuentro más inconsistencias… y no hay quien la entienda.

Hay un párrafo concreto en el que descrifrarlo me ha llevado varios minutos. Iba a copiarlo aquí, pero tampoco es plan, que en esta empresa tienen políticas muy restrictivas con las fugas de información, aunque el párrafo en sí no identificaba empresa, aplicación o funcionalidad ninguna, y era muy genérico. Simplemente está mal escrito.

Alguien debería rediseñar el interfaz de usuario de la lengua castellana.

Además esta está directamente relacionada con mi última queja de cascarrabias. En otro de los proyectos con los que estaba trabajando, un método de una librería recibía una serie de parámetros y, si alguna no era lo que esperaba, devolvía una ArgumentException.

En el código desde el que se llamaba a las funciones de esta librería había una serie de llamadas dentro de un try-catch, por lo que el primero que fallaba impedía que se ejecutaran los demás. Dado que todas estas llamadas dependían directamente de datos introducidos por el usuario, las posibilidades de que alguna no pudiera terminar estaban prácticamente aseguradas.

Ahora los métodos de esa librería tratan de manejar la situación excepcional como buenamente pueden y, de no ser capaces de hacerlo, optan por terminar con un simple return (porque tampoco me voy a inventar los datos si el usuario no los ha metido). No es una solución muy elegante pero para este caso nos vale, ya que sólo afectaba a una base de datos de búsquedas internas.

Deberían prohibir usar excepciones a según que personas… De todas formas yo siempre he sido muy maniático con la programación utilizando excepciones, y siempre me ha gustado gestionarlas en la capa en la que son susceptibles de generarse, sin andar propagándolas hacia arriba en ningún caso. Pero para opiniones colores…

Aplicación de línea de comandos en C#, nada más abrir la solución veo esto:

static void Main(string[] args) {
    if (args.Length != 1) {
        throw new Exception("Parámetros de entrada incorrecto. Se esperaba 1 y se han recibido " + args.Length);
}
[...]

Si sales de la aplicación con una excepción lo único que consigues es un molesto “La aplicación ha detectado un problema y debe cerrarse. Sentimos los inconvenientes ocasionados” y el botoncito de “enviar informe de errores” y demás.

Las excepciones (aparte de que no están para estas cosas, esto es una condición de la aplicación perfectamente predecible y tratable) se deben tratar y resolver dentro de la aplicación, e incluso si no se saben resolver, se debería salir de la aplicación de un modo completamente controlado.