Día filosófico: #1 "Soluciona los problemas, no los errores"

Los últimos días de trabajo han sido tan intensos como improductivos, con esa desagradable sensación de dejarse las neuronas desperdigafas en el camino de casa al ordenador, sin que nada avance. Como no puedo aportar gran cosa práctica (aparte del recién estrenado Google Desktop para Linux), hoy quiero sacar del tintero alguna reflexión que llevo madurando un tiempo.

Cuando al programar te encuentras con un fallo, puedes hacer dos cosas: solucionar el error, o solucionar el problema. La primera opción -y que he visto muchísimas veces, y que a veces se me escapa a mí también- lleva a cosas como bloques try .. catch que no hacen más que enmascarar errores, o casts o conversiones de código en la capa incorrecta (por ejemplo, cuando un valor incorrecto generar un error, parchear la línea en la que se produce en vez de la línea en la que se asigna, o el converter si hablamos de JSF). Perdemos el tiempo en un remedio que sólo soluciona un caso, en vez de arreglar lo que está mal.

Solucionar el problema implica hacer el esfuerzo de decodificar el mensaje de error y trazar la ejecución hasta localizar el punto del fallo. Implica conocer (aunque también es una buena forma de aprehender) y algo más de esfuerzo, pero resolverás no sólo el error detectado, sino muchos otros que vendrán después. Esto, que parece muy obvio, no siempre lo es. Hagamos examen de conciencia ;)

Posted by Juan Ignacio Sánchez Lara 16:37 Enlaces a esta entrada  



Google Desktop para GNU/Linux

Recientemente se ha publicado Google Desktop para GNU/Linux. Hace tiempo que lo uso en el trabajo (impagable cuando llegas a un sitio nuevo y no quieres molestar cada vez que necesitas un documento), y en casa lo echaba de menos.

Para instalarlo, puedes seguir la guía de comienzo. Si eres un afortunado usuario de Gentoo, puedes usar el ebuild para Google Desktop para Linux que ya hay en el bugzilla correspondiente (todavía no está en el árbol de Portage). Si, como yo, nunca has usado un fichero de ebuild para instalar nada, puedes seguir este sencillo HOWTO para ebuilds de terceros.

Ya no se dará la paradoja de que me cuesta más encontrar las cosas en mi ordenador que en Internet ;)

Posted by Juan Ignacio Sánchez Lara 16:22 Enlaces a esta entrada  



Programar sin el ratón (Hay que)

Una de mis innumerables manías en esto de la informática es que hay que programar sin tocar el ratón. Hace años, cuando los únicos entornos integrados de desarrollo eran malos y de pago, la gente programaba con vim y emacs, dando lugar a integrismos entre sus usuarios, humor ácido sobre sus atajos,.. Era una época en la que como no te sentases al menos cinco minutos con alguien o con un manual no eras capaz ni de escribir dos líneas. Era necesario saber. Eso sí, en cuanto aprendías, volabas.

Hoy en día no es así. Cualquiera es capaz de ponerse con el y crear en un momento un proyecto complejo a base de asistentes. Eso es bueno, porque trabaja por tí. Sin embargo, si no haces el esfuerzo personal de aprender (que ahora es opcional, no como antes), en vez de aprovechar el entorno te quedas en ser un (mal) usuario del mismo. Si nadie te lo exige (y nadie lo va a hacer) y tú no tienes la disciplina necesaria, puedes trabajar con un entorno durante años y ser igual de lento la primera semana que la última.

Mis sugerencias:

  • Si haces una acción dos veces, a la tercera, antes de hacerlo, consulta su atajo. Y si no tiene, configúralo tú.
  • Si desarrollas web, incluye el atributo accesskey en los enlaces, para no necesitar el ratón para navegar por las páginas.
  • Ponte el ratón en la mano mala, oblígate a aprender los atajos :)
  • Aprende la sintaxis de expresiones regulares que utilice, para hacer búsquedas de verdad y reemplazos masivos.
  • Entornos como Eclipse o Netbeans llevan años usándose, y están hechos por y para programadores. Si necesitas algo y no lo encuentras seguro que es porque no lo has encontrado todavía, no porque no lo tenga. Y si no lo tiene, seguro que es porque no lo necesitas.
PD: Algún día instalaré el vim para Eclipse...

Posted by Juan Ignacio Sánchez Lara 19:47 Enlaces a esta entrada  



Versiones (reflexiones)

En los últimos días...

  • Me he estado pegando con Acegi y el Sun Application Server. Éste tiene un bug que hace que no funcione Acegi como cliente. Lo curioso es que no lo tiene en ciertas versiones de 8.1, pero sí en otras posteriores.
  • Migré a GCC 4.2. Tras una semana (más o menos) recompilando mi sistema y mi mundo sorprendentemente el cambio de compilador no ha sido traumático, pero al recompilar se me actualizaron ciertas librerías, y...
    • Ciertas versiones de kdelibs hacen que la tecla de 'arriba' lance ksnapshot :-\
    • La última versión de los drivers propietarios de ati no funciona en Gentoo con DRI.
    • Los drivers open source de ati no valen para mi tarjeta (Mobility 9700), todo va lentísimo (pese a supuestamente soportar DRI).
    • Algo hace que ahora para moverme por palabras en vez de cursor+CTRL deba pulsar cursor+ALT (en ciertas aplicaciones).
  • Tras bajarme el instalador de JBoss e instalar el JBoss 4.0, leo que Seam 1.3 va sobre JBoss 4.2.
  • Hacer funcionar MyFaces sobre SJSAS 9.x es poco menos que imposible.
  • Sun no tiene soporte enterprise para versiones superiores a la 8 del servidor...
  • Los drivers de Oracle apestan y los de Hibernate sólo ayudan si trabajas con los últimos.
...versiones...

Posted by Juan Ignacio Sánchez Lara 19:34 Enlaces a esta entrada  



Las promesas de JBoss Seam

A pesar de sus intentos de impedirlo, JSF es mi apuesta para la web de los próximos años, gracias a su natural integración con Ajax. Sin embargo, "out of the box" no vale para nada. Pretendo empezar un nuevo proyecto y me disponía a descargarme "el lote" (MyFaces, Tomahawk, Tomahawk Sandbox, Facelets, Ajax4JSF, RichFaces y Dojo) cuando he recordado un artículo sobre los "ganadores del 2006" y su referencia a JBoss Seam, y he pensado en darle una vuelta.

Novedades principales de JBoss Seam:

  • Framework para EJB 3.0 pero compatible hacia atrás con J2EE, podría correr sobre un Tomcat. Estas promesas de "funcionamos con lo más último pero también con lo viejo" no me gustan nada, pero bueno...
  • Integra Ajax vía Ajax4JSF y/o ICEFaces.
  • Integran el motor de workflow jBPM.
Stay tuned...

Posted by Juan Ignacio Sánchez Lara 9:41 Enlaces a esta entrada  



Project Server 2007

desde hace unos meses vengo usando Microsoft Project Server 2007. Necesitábamos una (buena) herramienta de planificación y seguimiento de proyectos, y Project es LA herramienta. Estamos apostando por el software libre, y no hay cosa que más urticaria me dé que vender mi alma al diablo un poco más, pero, las cosas como son, no hay una opción mejor para un entorno empresarial.

Y claro, una vez una organización se mete con el Project, requiere el Server, para tener un repositorio centralizado de recursos (entre otras razones).

Pros:

  • Es muy completo: no sólo tiene el project, sino también repositorio de documentos, wiki, grupos de discusión...
  • Permite tener todo el trabajo centralizado, dando una vista transversal de todas las tareas pendientes en todos los proyectos, por ejemplo. Puedes integrar agendas, calendarios, contactos, avisos...
  • Proporciona un interfaz web (sólo para IE, por supuesto) para mostrar información y para realizar las tareas más comunes (como indicar el porcentaje de ejecución de una tarea).
  • Se puede acceder a él mediante servicios web, lo cual abre un abanico de posibilidades de integración con aplicaciones empresariales.
  • Se puede buscar a la vez en toda la documentación, wikis, foros, etc. de un proyecto.
Contras:
  • No dudo que la distribución automática de recursos pueda llegar a funcionar correctamente, pero la cantidad de información a proporcionar y la infinidad de parámetros hace que sea una tarea poco menos que imposible.
  • Demasiadas opciones de configuración, especialmente en lo referente a permisos.
  • Documentación lamentable.
  • Las alertas por correo son bastante burdas, poco más útiles que el spam.
  • La organización de los menús es... mejorable. Y la distribución en sitios / sitios virtuales / workspaces / proyectos es confusa y más complicada de lo necesario.
Me gusta, especialmente si se exprime al máximo (foros, wiki, gestor documental...). Es un producto mejorable todavía, pero casi imprescindible para cualquier empresa de desarrollo de software.

Eso sí, hasta que Microsoft lo libere, yo seguramente invierta tiempo en el prometedor Projecto Dune: su objetivo es integrar en una aplicación web (Hibernate + Spring + GWT) todo lo necesario para la gestión de proyectos (orientado a Scrum). Ya tiene gestión de versiones, de fallos...

Posted by Juan Ignacio Sánchez Lara 18:20 Enlaces a esta entrada  



El talento y el desarrollo (obviedades)

vamos a hablar de obviedades sobre el talento y el factor humano:

Cinco albañiles producen más o menos cuatro o cinco veces más que uno si tienen la materia prima adecuada. Diez personas no impedidas pueden cargar más o menos diez veces más cajas que una persona.

Cinco programadores NO acaban un proyecto cinco veces más rápido que uno. Cinco programadores haciendo una jornada laboral un 50% mayor no acaban un proyecto el 50% antes.

Y, por mucho que cobren lo mismo, la diferencia entre programadores puede no ser grande, sino ser absolutamente incomparable. Algunas citas:

  • De un artículo que opina (yo también) que se puede cerrar el departamento de recursos humanos:
    • Los mejores lo hacen mucho mejor que los mediocres: "En el mundo del diseño informático, los mejores lo hacen entre 50 y 100 veces mejor que el promedio, y la cifra aumenta, conforme se incrementa la complejidad de la tecnología" --Pilar Jericó. La Gestión del Talento. Pearson Educación

    • "La diferencia entre los promedios y los mejores ya no es de 1:2, como en el pasado. Es 1:100 o incluso 1:1000." --Nathan Myhvold (Ex-director de I+D de Microsoft)

  • Errores de selección de personal:

Gracias a Navegápolis por aportar contenido de calidad (este post es poco más que una recopilación de entradas suyas).

ACTUALIZACIÓN: el mismo día, unas horas después, otra persona hacía una reflexión muy similar sobre la importancia del talento de los programadores.

Posted by Juan Ignacio Sánchez Lara 16:20 Enlaces a esta entrada  



Elegir un IDE para Java

Si quieres ser productivo debes usar las mejores herramientas, y eso incluye los frameworks utilizados en el proyecto, el sistema operativo, el entorno de desarrollo, el servidor de aplicaciones... Periódicamente busco estudios, comparativas, datos... que me lleven, cual ave migratoria, a terrenos más cálidos. Casi anualmente el cuadro de búsqueda de Google se llena con los mismos términos, básicamente permutaciones de "eclipse jdeveloper netbeans myeclipse 200x", casi nunca con resultados aceptables. Es muy difícil encontrar datos objetivos para comparar diferentes IDEs. Esto tiene un motivo bastante lógico: no puedes símplemente lanzar un benchmark o una batería de tests unitarios para probar un IDE. Necesitas usarlo durante meses para probarlo.

Los principales contendientes en estos momentos son:


La (pobre) pesca de esta primavera devuelve los siguientes resultados (¡agradeceré toda aportación posible!):
Salvo excepciones, lo más usado es Eclipse. La sensación general es que, de los de pago, el IntelliJ IDEA debe ser muy bueno (no lo he probado). Y, por último, que NetBeans ha dado un gran salto en la versión 5.5, pero parece que todavía no es suficiente.

Mi experiencia personal se reduce a JDeveloper, Eclipse y algo de NetBeans. A priori la versión 5.5 de NetBeans me pareció impresionante, tanto por facilidad de uso como por prestaciones e integración. JDeveloper siempre me ha parecido lamentable en mayor o menor medida, y a menudo ni siquiera es nombrado en los artículos (aunque con frecuencia por su licencia). Uso sobre todo Eclipse, pero tuneado con muchos plugins. Eso se puede mitigar con MyEclipse (de pago), aunque últimamente en la página oficial parece que están haciendo un esfuerzo extra de empaquetado para echar a andar "out of the box" en diferentes entornos. Parece que han visto llegar fuerte a NetBeans. En el trabajo hemos escogido MyEclipse, sobre todo porque integra Matisse, el editor Swing de Netbeans (uno de sus puntos más fuertes), y de esta forma todo el área de informática podía usar la misma herramienta. Yo habría preferido que cada uno eligiese con la que estuviese más cómodo (pienso que lo importante es el servidor de aplicaciones), pero creo que ha sido una buena elección.

Lo que está claro es que las diferencias no son muy grandes. Cuando Eclipse nació no había buenos entornos de desarrollo libres en Java (Forte/Netbeans estaban muy lejos), pero esto ya no es así. Así como el talento de un programador sí puede aumentar la productividad en varios órdenes de magnitud, un ide no.

¿Una recomendación? Instala Eclipse (todo lo completo que puedas) o Netbeans, aprende todos los atajos, y desenchufa el ratón para programar.

Posted by Juan Ignacio Sánchez Lara 15:43 Enlaces a esta entrada  



Facelets

Si has llegado hasta aquí buscando novedades sobre Facelets, puedes ir cerrando, porque tan sólo es una sugerencia rápida: si trabajas con JSF, ya sea comenzando o acabando, no dudes en usar facelets. La inversión necesaria (en tiempo y esfuerzo) es mínima, y tiene (casi) todo lo bueno que tiene Tiles, pero orientado al mundo JSF. Personalizar los componentes JSF es fundamental (mediante recubrimientos o composiciones), y JSF no hace NADA por ayudarte en ese aspecto. Es curioso que un proyecto tan parado (aunque dicen que no está muerto, la última beta se remonta a diciembre del año pasado, y la última estable a junio) sea tan imprescindible.

En IBM tienen tutoriales introductorios y avanzados. Si no has intentado programar componentes con JSF esto te parecerá trivial, como a mí ahora, pero créeme que los que hemos intentado ser "ortodoxos" programando componentes "a mano" agradecemos la simplicidad de Facelets (nuevamente, los estándares no valen para nada).

Posted by Juan Ignacio Sánchez Lara 20:56 Enlaces a esta entrada  



Los estándares no valen para nada

Los estándares, en informática, son lentos de especificación, tardíos de publicación, ineficaces e insuficientes.

Unas cuantas muestras:

  • WCAG: estándar de accesibilidad web, la versión 1.0 data del 99 y desde entonces no han sido capaces de ponerse de acuerdo en uno actual y viable.
  • SQL: ni siquiera soporta realmente algo tan elemental como jerarquías padre-hijo (lo que Oracle implementa mediante "connect by"). Eso hace que el SQL de Oracle sea incompatible con el de MySQL, que es incompatible con PostgreSQL... Las implementaciones en las BBDD ni siquiera son capaces de ponerse de acuerdo en los limitadores de cadena.
  • ANSI C: tres cuartos de lo mismo, en cuanto intentas hacer algo, el compilador estricto se queja.
  • JSF: estándar orientado a sustituir la programación de HTML por otra orientada a componentes, y en su versión 1.0 ni siquiera era capaz de hacer todo lo que éste hacía (¡y además era incompatible con él!). En la 1.2 algo ha mejorado, pero los componentes estándar son irrisorios, requiriendo usar múltiples librerías para tareas habituales (en el último proyecto acumulo ya MyFaces + Tomahawk + Sandbox + Facelets + Ajax4JSF + RichFaces, y suma y sigue).
  • JCR 1.0: ¿¡nadie se dio cuenta de que no había un mecanismo para asignar permisos!?
  • (x)HTML, CSS, Javascript...: cada navegador es un mundo aparte. Un buen desarrollador web se ve obligado (además de a acudir a terapia) a aprender hacks para afinar el resultado y que funcione al menos en los mayoritarios.
  • XML: destinado a ser un santo grial de la informática, constantemente aparecen incompatibilidades entre los parsers. Es raro que ni siquiera un fichero de configuración algo grande funcione correctamente en varios motores. Iba a ser adecuado para procesamiento automático, pero en la práctica es lento. También era apto para lectura humana, pero es engorroso (quien haya programado Ajax a capella, que compare trabajar con JSON y con XML).
  • Servicios Web: lo que debía ser una forma sencilla de conectar aplicaciones saltándose cortafuegos, se convierte en una colección de siglas (¿habéis leído introducciones a servicios web mediante Java?) difícil de comprender y de poner en práctica de forma productiva. A menudo, con incompatibilidades entre implementaciones. Y sorprendentemente (la web era ya madura) cuando se especificaron se dejó para más tarde la seguridad...
Los únicos que de verdad han funcionado, los mpeg (mpeg4, video, y mp3, audio), debidos a una limitación: si te sales del estándar, el reproductor casero o portátil deja de funcionar. Igual pasa con ethernet...

Moraleja: si pretendes hacer funcionar un estándar, vende implementaciones de sus algoritmos programadas en circuitos. Ellos no entienden de excepciones. Ójala se hiciese ya un "navegador hardware".

Corolario: Microsoft triunfa porque impone "estándares". Hibernate triunfa porque abstrae de SQL. Spring triunfa porque no se ciñe a ningún estándar. Struts triunfó porque solucionaba todo lo que J2EE no solucionaba... Be propietary, my friend...

Posted by Juan Ignacio Sánchez Lara 21:53 Enlaces a esta entrada  



Google Code Search

Está claro que Google ha cambiado -que no mejorado- la forma en que programamos. Hace no tanto las mejores herramientas de un programador eran la ayuda del MSDN del Visual Studio (si tu ordenador tenía las gigas necesarias para instalar la referencia completa de las MFC) y las páginas de man. Si no sabías cómo hacer algo, aprendías con libros. Y cuando algo no funcionaba, tenías que averiguar porqué.

Ahora cada vez se programa menos y se googlea más. Es más, cada vez se sabe menos y se cortapega más. A pesar del gran avance que suponen los errores que muestran las excepciones sobre los mostrados cuando algo en C fallaba, no sabemos interpretar lo que nos dicen. Tan sólo pegamos en Google la excepción, la librería que estamos usando, y, con suerte, alguna otra cosa. Escaneamos los resultados obtenidos y cortapegamos trozos y trozos hasta que resulta que uno funciona.

Hace tiempo apareció Google Code Search, una herramienta de búsqueda en código libre, y hace poco ha salido de beta.
Por si no te es suficiente, incluso hay un plugin para eclipse que integra Google Code Search. Tú sabrás si quieres instalarlo o no ;)

Actualización: enlace al plugin corregido

Posted by Juan Ignacio Sánchez Lara 21:06 Enlaces a esta entrada