Ideas + Ingeniería del Software

¡De mudanza!

2011-02-19T19:27:00.001Z

Estoy en proceso de migración de blogs y demás gaitas a un único servidor: http://www.juanignaciosl.com . A partir de ahora todo el contenido (pasado, presente y futuro) relativo a mí lo podrás encontrar ahí.

Concretamente, el apartado de Ingeniería del Software (el sustituto de este blog) lo encontrarás en http://www.juanignaciosl.com/categorias/ingenieria-del-software . También hay los siguientes apartados:

SEO, redes sociales...

2010-12-01T19:04:00.005Z

Año y medio sin escribir... ¡Cuánto tiempo!

Quién me lo iba a decir, es un tema viejo el que me anima a escribir una nueva entrada. Estoy aprendiendo sobre SEO y redes sociales, comenzando a ver de primera mano conceptos de los que llevo años leyendo, y aplicando técnicas para mejorar posicionamiento y visitas.

Formo parte de Notedetengas, un magazine cultural independiente. Escribimos sobre todo acerca de música y teatro (crónicas de conciertos y actuaciones, principalmente), y es algo que lleva un trabajo monumental. Mucha gente y mucho esfuerzo invertido diariamente (y de forma muchísimo más disciplinada de lo que cabría esperar) del que hay que sacar el mayor provecho posible. Y no hablo de beneficios económicos, sino en términos de visitas. Creo que invertimos una cantidad de tiempo brutal y hacemos un trabajo que debe revertir en un mayor número de usuarios.

Por si esto no fuese suficiente, recientemente hemos publicado un proyecto de conciertos acústicos. Fuertemente inspirados por la Blogotheque, comenzamos AU! (Acordes Urbanos)pretendiendo hacer algo similar en nuestra ciudad. ¡Más trabajo de posicionamiento y de visitas!

¿Y toda esta introducción por qué? Porque una de las medidas más eficaces que puedes hacer es invertir en Facebook y redes sociales en general. Y hoy me he topado con los interesantes resultados de un estudio:

Informe redes sociales IAB Spain 2010 - Noviembre 2010

View more presentations from IAB Spain.

Notas a destacar:

Tuenti parece parar su progresión, pero sigue siendo la "2ª potencia" en este país. Su baza es la facilidad. Equipara a Facebook en menores de 24 años.
Gran crecimiento (especialmente en notoriedad) de Twitter. La temática más habitual es la cultura y entretenimiento.
Los usuarios de redes sociales son más activos en el Mundo Real™ que los no usuarios. ¡Buena noticia para los que anunciamos conciertos!
No hay una percepción negativa de la publicidad en las redes sociales. Se nota que tienen la lección aprendida.

En próximas entradas, más notas sobre mi aprendizaje en esto de técnicas de SEO y de mejora de visitas... Stay tuned!

Opera Unite: involucionando la web

2009-06-16T15:29:00.005+01:00

Hoy Opera ha puesto fin al hype que ellos mismos comenzaron hace un par de días, desvelando su proyecto secreto: Opera Unite. Aunque comercialmente se pueden decir muchas más cosas, lo resumiré en un servidor web dentro del navegador. Mediante esto y un API se desarrollan servicios que se ejecutarán en tu ordenador. Por ejemplo, reproductor multimedia, gestor para compartir ficheros, páginas web, chat...

Actualización 0906161825: Ender Wiggins, un tío mucho más responsable que yo, lo está probando antes de juzgarlo (ver comentarios), por lo que tacho un par de cosas de las que me quejo sin deberlo (no lo borro para que quede constancia ;) ).

Vaya por delante que (todavía) no lo he probado, pero el concepto en sí no me gusta, por muchas razones:

La fundamental es que obviamente tienes que tener el ordenador encendido constantemente para que esto sea útil. Somos muchos los hace años (incluso hoy, seguro) nos montamos un servidor ftp, web o similar para poder acceder a nuestros ficheros o colgar nuestras páginas web, pero se debía a que no había demasiadas alternativas posibles. Hoy en día, con servicios de almacenamiento baratos (o muy asequibles, más que el consumo energético de nuestro sobremesa) podemos cubrir esto fácilmente. Algunas de los siguientes motivos por lo que no me gusta no dejan de ser derivados de esto.
No quiero poder acceder a mi ordenador desde cualquier parte. Lo que quiero es poder colgar mi contenido en la red y poder acceder a él donde sea.
Aún en el caso de querer acceder a mi ordenador, las alternativas son incontables: servidores web, ftp, ssh... Servidores multimedia que además convierten el formato del contenido (hay varios que se orientan a ser servidores para la Wii, por ejemplo). Hasta WinAmp ofrece desde hace tiempo un servidor propio.
El modelo p2p de distribución de contenido se popularizó entre otras cosas por las implicaciones legales de que un proveedor se convirtiese en distribuidor de contenido. La SGAE y similares se estarán frotando las manos al ver la cantidad de incautos que van a compartir sus colecciones de mp3.
Hay alternativas para todas las funcionalidades que ofrece que seguro que son mejores. No creo que su servidor web pueda competir con Apache, por ejemplo.
Siempre se ha podido compartir ficheros (email, directamente a través de cualquier messenger, servidores propios...). No hay nada novedoso en esto.
Normalmente si quiero compartir ficheros lo hago con Dropbox, que me da 2GB gratis. Y si mis necesidades son mayores, por 10$ al mes tengo 50GB. Sólo el consumo energético de tener el ordenador encendido a todas horas seguro que es mayor. Es un cliente muy ligero, que ni se nota que está corriendo, y me permite tener sincronizados directorios entre varios ordenadores, y también compartir mediante enlaces públicos. Y mi contenido siempre está accesible en su web.
Si quiero compartir de verdad, lo hago mediante p2p.
¿Realmente queremos comprometer aún más la seguridad de nuestro ordenador personal?
¿Qué valor van a tener los enlaces a páginas alojadas en PCs, que dependen de tener el ordenador encendido? Además, obviamente la fiabilidad de un PC y una red casera no tiene nada que ver con un servidor "de verdad".
~~Se necesita, sí o sí, usar DNS dinámicas.~~
Nuestras conexiones a internet suelen ser asimétricas, con una velocidad de subida irrisoria. Poner contenido online es lento una vez, pero todos los accesos a ellos son bastante rápidos. Sin embargo, con Opera Unite serán lentos siempre (hasta que Telefónica quiera, al menos).
En la época en la que las prácticas se entregaban en disquetes sí era muy útil montarnos un servidor ftp. Hoy en día, con una memoria USB de 16GB en el bolsillo, no lo es tanto. Y con almacenamiento en red gratuíto, menos.
¿Qué pinta toda esta funcionalidad en el navegador?
~~A la gente ya le costaba configurar el router para redirigir puertos del eMule, esto será lo mismo.~~
...

El título del artículo, "involucionando la web", es, sin duda, exagerado e injusto. El producto en sí mismo puede estar bien y en algún caso puede que incluso sea útil, especialmente para usuarios sin conocimientos técnicos que quieran montar un servidor casero fácilmente. Sin embargo, necesitaba poner el contrapunto a lo que ellos dijeron que significaría, "reinventaremos la Web", y a lo que veo en la blogosfera (revolución, y 2...). Desde hace años la tendencia que parece claro que funciona es aligerar los equipos personales y utilizar tanto contenidos como aplicaciones disponibles en la red. Esto es un paso al contrario.
Ójala GDrive, si finalmente se materializa, cumpla las expectativas creadas: gran(-dísimo) espacio de almacenamiento, API para acceder al contenido, búsqueda completa... Eso sí sería un paso adelante.

Redes sociales (II): Firefox Collections

2009-06-14T17:34:00.005+01:00

Aunque en estos meses de ~~humo~~ nubes hablar de redes sociales suena demodé, tenemos novedades para Firefox que nos pueden hacer reflexionar sobre ello.
Las Firefox Collections son conjuntos de extensiones, listados, que puedes compartir y a las que te puedes suscribir. Por ejemplo, la primera colección que iba a figurar en el editor's pics no podía ser otra: Web Developer's Toolbox. Hecha por el usuario Mozilla (pero podría ser cualquiera), recopila las extensiones que ellos consideran fundamentales para el desarrollo web. Yo, una vez me instale la extensión 'Add-on Collector', puedo suscribirme a esta lista. Al hacerlo podré instalar las extensiones que la componen, recibiré actualizaciones si añade alguna al listado... Es una funcionalidad social pero muy potente. Cada sector puede colaborar generando un lote de extensiones interesantes: brokers de bolsa, bloggers, desarrolladores...
Esto genera una funcionalidad colateral muy interesante: sincronización de extensiones entre navegadores. Es algo que llevo necesitando desde que comencé a usar Firefox, y, aunque había formas de hacer algo similar, nada que me satisficiese.
No sé cómo se lo plantearon en Mozilla: ¿Cubrir la necesidad de sincronizar extensiones y de ahí salió la idea de compartirlo? ¿Al revés? ¿Ambas a la vez? El hecho es que la funcionalidad social (compartir colecciones) es la generalización de un caso particular (sincronizar mis extensiones) de interés para el usuario. Este es un ejemplo perfecto de solución del problema del arranque en frío en redes sociales comentado con anterioridad:

Cubre una necesidad personal existente...
... y a la vez aporta un gran valor añadido.

Dos nuevas notas mentales que siempre denería tener presente:

Cuando vayas a implementar algo, piensa si en vez de resolver el caso específico puedes encontrar una solución más general...
... y piensa si esa solución general tiene potencial con un botón "compartir con más gente".

CexC, Teiid y el estado del blog

2009-06-14T16:50:00.004+01:00

Llevo mucho sin actualizar el blog (dos meses), y antes de la última entrada el ritmo ya había bajado. Alguna razón tenía que haber, además del habitual cansancio. Esta página siempre ha sido una vía de escape de mis inquietudes tecnológicas, pero últimamente me parecía estar totalmente desinteresado de las novedades del sector. El escaso tiempo libre y el que me ocupa la fotografía hacían el resto.
Dándole un poco de vueltas este desinterés realmente no existe, lo que ocurre símplemente es que lo cubro en horas de trabajo. Hasta ahora mi trabajo había sido de desarrollo o de gestión de proyectos, lo que apenas dejaba margen al cacharreo con nuevas tecnologías, por lo que esa necesidad que realmente tengo de estar al día, de probar cosas nuevas, se cubría en casa.
Desde finales del año pasado estoy trabajando en el Centro Experimental del Conocimiento (CexC para los amigos), y mi papel es, en gran medida, realizar un esfuerzo de investigación e innovación. Para nosotros es fundamental evolucionar nuestra forma de trabajo y mejorar constantemente las herramientas a utilizar, y una buena parte de mi tiempo se va en leer artículos, noticias, descargar nuevas aplicaciones o componentes, y probarlos y pegarme con ellos. La verdad es que da gusto cuando, en este sector tan condicionado por los plazos y clientes, se tiene oportunidad de invertir una buena parte de tu tiempo en tareas de innovación, y se confía en la adopción de nuevas tecnologías en vez de atarse a la tradición.
Como medio para dar algo más de visibilidad a esto, y como medio de comunicación, en el CexC acabamos de abrir un blog de nuevas tecnologías en el que ir mostrando al menos una parte de esta inversión. Todavía está en pañales, pero os agradecería que figurase en vuestros marcadores o lectores RSS.
La primera entrada habla de Teiid, una fantástica herramienta para virtualización de datos que acaban de liberar en jboss.org. Cualquiera que haya realizado una aplicación empresarial con varias fuentes de datos diferentes sabrá valorarla como corresponde, en mi opinión. El primer artículo es introductorio, pero iremos ampliando con ejemplos prácticos de esta y otras tecnologías de JBoss con las que trabajamos desde hace tiempo.
Todavía no dispone de comentarios (espero activarlo en breve), así que quien quiera abrir el diálogo que lo haga por aquí mismo.
Nos vemos por el CexC :).

Postmortem: estimaciones y creación del sprint backlog

2009-04-18T10:10:00.005+01:00

Estamos cerrando el último proyecto, una aplicación de gestión de datos con múltiples perfiles que controlan el trabajo y la información introducida por los demás. Acaba de entrar en explotación con bastante éxito: ni un error en los cuatro primeros días de uso, fundamentales porque corresponden con una primera fase que tiene un plazo límite. A partir de ahora, mantenimiento correctivo y algo de evolutivo.
Es un buen momento para comenzar el postmortem y analizar los errores cometidos.

Hemos usado Scrum como metodología, y la conclusión es que nos ha aportado tan poco como cualquier otra metodología que hubiésemos usado, pero al menos no ha molestado. No creo que nos haya aportado un auténtico valor, pero creo que estamos en el buen camino. El gran reto que teníamos para el desarrollo del proyecto era el uso de una pila de desarrollo nueva para casi todos, y contra eso no hay metodología que valga.

El product backlog se hizo a partir de las reuniones de contacto con los usuarios y de los primeros documentos de prototipado y requisitos que nos pasaron. Hasta ahí, bien, no es un artefacto que tenga mayor complicación.

Para estimar el product backlog hicimos planning poker con el equipo, tras haber contado de qué iba el proyecto. A todas luces la estimación era muy optimista, y se cumplió aquello de que los técnicos son positivos y que los gestores son pesimistas. Sin que sirva de precedente, los gestores tenían razón. Sin embargo, creo que si el mismo equipo volviese a comenzar el proyecto sí cumpliría las estimaciones que salieron de esa reunión. La experiencia en la tecnología y una mejor gestión de los requisitos habrían hecho que se hubiese podido implementar en los tiempos dichos.

Creo que nuestro gran error desde el punto de vista de la metodología fue la creación del sprint backlog. Lo hizo una persona (yo, como Scrum Master). Gran equivocación. Lo debe hacer el equipo en conjunto. El equipo careció de una visión global del proyecto, lo cual no trajo más que problemas:

Se adquirieron tareas en el orden incorrecto.
No se sabía qué era común y qué no, así que era más difícil organizarse para la reutilización.
"Marchas atras" por mala comprensión de las tareas.
Funcionalmente se depende del criterio de una única persona.
La estimación de las tareas habría sido más acertada con un mejor conocimiento del problema.
...

Ya en un plano más técnico, otra fuente de problemas iniciales fue la ausencia de un modelo de entidades del que partir. Se pretendió hacer de forma totalmente incremental, exprimiendo al máximo la generación del modelo de datos de Hibernate a partir de las clases. En los anteriores proyectos, como ya he comentado, se nos imponía que un analista crease el modelo de datos, y que eso se tomase como base para comenzar el desarrollo. El extremo contrario tampoco es útil:

No es una tarea trivial, y es poco tolerante a errores. No pasa nada si haces mal un campo en una pagina, pero un error en el modelo de entidades puede tener consecuencias bastante dramáticas. Hacerlo exige un conocimiento profundo de los requisitos.
Una equivocación de una persona puede tener un desagradable efecto de malentendidos de los requisitos en cadena.
No es fácil compartimentar inicialmente para que la gente pueda trabajar independientemente.

Para la próxima...

El product backlog lo hará el Scrum Master como esta vez, antes de la primera reunión (tampoco tiene sentido movilizar a más personas para él).
En el sprint meeting el sprint backlog se hará entre todos los miembros del equipo. En vez de llevar a la reunión el sprint backlog prefabricado, leerlo, y estimar a partir de esa lectura, se generará durante ella, y tras la creación de cada tarea se hará la estimación de la misma. Sí, nos llevará mucho más tiempo, pero no será perdido, sino invertido.
En caso de tratarse de una aplicación de gestión, probablemente durante el propio sprint planning se hará un modelo de entidades (entidades del sistema y su relación entre ellas, sin necesidad de entrar a nivel de propiedad). Algo muy básico, pero que permita tener un punto de arranque común y afianzar los requisitos. Eso sí, me mantengo en la opinión de que con Hibernate ya debemos trabajar en términos de entidades y no de tablas.

Java en Google App Engine

2009-04-08T15:11:00.003+01:00

Hasta ahora el hosting accesible (gratuito o de precios ajustados) era territorio dominante de la plataforma LAMP (Linux + Apache + MySQL + PHP) o derivados. Este ha sido uno de los factores determinantes de la proliferación de herramientas open source para foros, blogging, etc.
Por el contrario el mundo empresarial está copado, también en gran parte, por Java (aunque sitios como Flickr o Yahoo! demuestran que PHP es un sistema que no tiene que limitarse a eso, pero este es otro tema).
Hoy Google ha anunciado la disponibilidad de Java en Google App Engine. Además, con soporte para JPA. Por fin hay una alternativa real al LAMP (¡ojo, que no tiene nada de malo, pero las alternativas siempre son buenas!).

Los ordenadores son, esencialmente, deterministas

2009-03-22T14:40:00.003Z

Los ordenadores, fallos hardware aparte, son autómatas deterministas: dado un estado inicial, una serie de operaciones llevan siempre al mismo resultado.
Una conclusión de esto es que no hacen "cosas raras". Puede haber cosas mal hechas, claro está, pero sus efectos son predecibles.
Un caso paradigmático de esto son las librerías. En todas hay bugs, claro, pero pocos. Si algo "no funciona" revisa antes tu código. Las librerías de código abierto son usadas por millones de desarrolladores, y revisadas por gran parte de ellos (¿aún no has asociado las fuentes a los binarios en Eclipse? ¿A qué esperas?). Sin embargo, tu código es nuevo y sólo tuyo, probablemente el problema esté ahí.
Cuando llamamos a un SAT lo primero que nos preguntan es ¿está enchufado? Sí, es irritante, pero, ¿compruebas que tu código lo está? El determinismo hace que para solucionar la mayor parte de los errores en el código no sea necesario ni pensar. Símplemente un análisis metódico desde el error nos conduce al error: vete a la línea que falla y vete "tirando del hilo". El problema aparecerá solo.

PS: ¿Ah, que estás utilizando librerías propietarias, sin el código? Mmm... ¡Buena suerte!

IPhone 3.0 y ubiquidad

2009-03-19T18:53:00.006Z

No es mi costumbre usar este blog para hacer reseñas de productos, pero sí me gustaría hablar un poco del IPhone, a cuento del reciente anuncio de la versión 3.0 de su sistema operativo.
Se habla mucho de cloud computing, Web 3.0 y demás milongas últimamente, que, en mi opinión, sólo sirven para alimentar los blogs, las columnas en las revistas, y con ello, las nóminas, de supuestos visionarios. Nuevas etiquetas para productos que ya existen.
Sin embargo, la auténtica evolución (no creo que haya revoluciones a la vista) de Internet es la presencia ubíqua de la misma. Hace aproximadamente cinco años trabajé en proyectos de I+D sobre este tema, y se veía claro que el futuro pasaba por ahí. Sin embargo, el precio de los dispositivos y la cara y escasa cobertura de Internet de calidad lo hacían imposible.
A día de hoy los dispositivos están al alcance de cualquiera, y la conexión es más que aceptable, así que esto está a punto de estallar. Google lo sabe y se ha posicionado con Android. Apple, con su iPhone, ya lo está experimentando.
La versión 3.0 contiene dos bombas potenciales en este aspecto: las compras in-app y la conexión de dispositivos.
Sí, todos gritábamos por tener, por favor, cortapega ("ortodoxo", ya que con jailbreaking ya se podía), tethering y A2DP (Bluetooth Estéreo). Pero lo que puede ser una revolución ubíqua es lo otro.
Las compras in-app permiten un modelo de negocio basado en micropagos, para ofrecer contenido de calidad (de pago). Off-topic: ¿tendrá el siguiente iPhone una pantalla de lector de ebooks a color y reventará el mercado?
La conexión a dispositivos permitirá conectar cualquier aparato a Internet, sin requerir una dedicada. Ya estoy empezando a pensar aplicaciones online a aparatos que ahora son offline...

Quien quiera innovar y forrarse, que piense en ubiquidad y se deje de modas pasajeras.

Artesanía

2009-03-19T09:56:00.002Z

El desarrollo de software tiene más de artesanía que de ingeniería. Sí, hay métricas, calidad, automatizaciones... Pero lo que requiere de la persona que lo realiza es que sea un buen artesano, que haga las cosas con esmero, meticulosidad...

Cuándo hacer el modelo de datos

2009-03-08T15:15:00.002Z

Si me preguntasen por el mínimo común denominador de la aplicación de las metodologías tradicionales que he visto en los últimos años, respondería sin dudar el modelo de datos. La gestión de los requisitos es muy variable, el diseño y la construcción varían enormemente... Sin embargo, el momento y la forma en que se hace el modelo de datos siempre era la misma. Una vez recogidos los requisitos, durante el análisis, el paso clave que marcaba, en cierto modo, el fin del trabajo del analista y el comienzo del resto, era la validación del modelo de datos.

En las metodologías tradicionales se hace en dos partes: en la fase de análisis se hace el modelo lógico, y en diseño se hace el físico. En la práctica siempre he visto que esto se fusionaba. Quizá por las herramientas, quizá por lo innecesario de la división, siempre se hace directamente el segundo.

Desde que uso Hibernate había querido aprovechar al máximo la potencia de su mapeo relacional, relegando el modelo de datos a un segundo plano en favor del modelo de clases. Esto, que parece un detalle menor, en mi opinión tiene una gran importancia práctica. Hacerlo implicaría que el analista/diseñador haría, en vez del modelo, directamente las clases, las cuales generarían el primero automáticamente. Expuse esta idea esgrimiendo una serie de ventajas:

El trabajo de modelado aportaría más información, ya que los modelos Java más las anotaciones de persistencia aportan más información y valor que las tablas (se introducen validaciones de datos, propiedades calculadas, documentación...).
Eliminaríamos el problemático trabajo de mapear tablas existentes.
Adelantaríamos el trabajo de la programación de las entidades.
Podríamos anticipar cosas como pruebas automáticas para verificar la corrección del modelo.
Personalmente trabajo mejor con una herramienta de desarrollo que con una de modelado. Andar con el ratón, dobles clicks y diálogos me parece engorroso y lento, aunque esto ya son preferencias de cada uno.
No renunciamos a la información gráfica, ya que podemos generar diagramas tanto de clases como de objetos mediante ingeniería inversa (NetBeans es realmente útil para esto).

La idea no prosperó, y los siguientes proyectos se hicieron como anteriormente.

Al pasar a metodologías ágiles, al desaparecer estas fases, toca decidir cuándo realizar este trabajo. Scrum obviamente no entra en esta decisión, así que, ya con la capacidad de decisión, me adherí al principio de diseño contínuo y además adopté las ideas anteriores. De esta forma, no se haría el trabajo explícito de modelado de los datos, sino que, a medida que se avanzase en la aplicación, se iría mejorando a través del propio diseño de las clases.

Ya con el proyecto en desarrollo, saco las siguientes conclusiones:

No realizar análisis del modelo de datos, sino trabajar directamente en el diseño de las clases, es muy práctico: es mucho más tolerante a los cambios (hemos pasado de claves deferred a compuestas de forma trivial, por ejemplo), facilita el trabajo en equipo (no más "lanza de nuevo el script de base de datos, que he cambiado el esquema")... Me reafirmo, por tanto, en los puntos expuestos antes.
Desaparece la mentalidad de "tenemos que ceñirnos al modelo de datos a cualquier coste". He visto auténticos malabarismos por parte de desarrolladores por querer respetar el modelo del analista por todos los medios. El hecho de no tenerlo tira esa barrera.
Pese a esto, sigue siendo necesario hacer un trabajo previo de análisis. Comprender las clases y las relaciones entre ellas es fundamental para el desarrollo del proyecto. No es necesario especificar desde un principio cada propiedad de cada clase, sus longitudes máximas y sus validaciones, pero sí es importante tener claro lo antes posible el esquema general. Los desarrolladores tendemos a centrarnos en "pantallas", y en una no está la auténtica lógica de las relaciones entre los datos.

Para el siguiente proyecto estoy pensando incluso en hacer una primera versión del modelo de clases en el primer Sprint Meeting. En este creamos una tarea específica para ello, pero esto hace que el conocimiento quede en una sola persona. Creo que el trabajo de hacer una primera aproximación, incluso antes de la estimación de las tareas, ayudaría a todo el equipo a comprender el problema a resolver y la complejidad del desarrollo.

¿Qué hacer cuando los usuarios/clientes se ponen nerviosos?

2009-02-20T15:52:00.003Z

Como dirían en El Hormiguero... "¡Los usuarios, ese gran desconocío''!"

Hoy se nos han puesto nerviosos los usuarios/clientes. Hacemos aplicaciones a medida, y hace un par de semanas tuvimos la última reunión (aún hay requisitos sin cerrar, pero bueno, tenemos claro que tenemos que aprender a convivir con eso). Nos han perido que quieren ver algo cuanto antes (obviamente cambiando la planificación acordada).

Ante una situación así se me ocurren tres alternativas:
a) Como no es lo pactado, nos ceñimos a lo hablado, así que dentro de mes y algo nos vemos. Hasta entonces, dejadnos tranquilos.
b) Ok, el cliente siempre tiene la razón, así que nos adaptamos. Cambiamos la duración del sprint, adelantando la demo, aunque reduciendo el número de historias de usuario que presentamos.
c) Nos mantenemos como estamos, pero, como el cliente siempre tiene la razón, os daremos versiones previas de prueba (abriendo acceso a alguno de nuestros servidores).

La a) es la típica en la programación por contrato, la ortodoxa, la que te enseñan en clase. Tiene sus ventajas y sus inconvenientes. Por un lado, sí, estás en tu derecho de "plantarte", ya que así está acordado. Pero por otro, no satisfaces la solicitud del cliente. Personalmente no me gusta. Predispones al usuario a tirar a la basura lo que le enseñes en la fecha acordada. Y, no lo olvidemos, en ese momento pueden tener razón (sí, señores, los desarrolladores también nos equivocamos).

La b) es la que inicialmente pensamos. No es demasiado mala, ya que no aumenta la "densidad de trabajo", y contenta a los usuarios. Pero presenta varios problemas. La duración del sprint no se debe cambiar, y mucho menos por gente no comprometida. Además, es tarea específica del Scrum Master evitar este tipo de situaciones. Y, dejando ya de lado Scrum, te permite menos margen de error. Aunque la "densidad de trabajo" no cambie, es más difícil cumplir el plazo.

La c) es la que finalmente se va a tomar. No sólo no rompe reglas de la metodología, sino que va a potenciar que el trabajo se haga como se debe. Ya habíamos quedado clara la "definición de hecho" y la integración contínua, así que en cualquier momento se podría desplegar el código del repositorio para probar. Y, además, permite satisfacer la necesidad del usuario (¡incluso mejor que con la opción b), ya que podrá ver más antes) e implicarle más. Tendremos feedback antes, minimizando el impacto del cambio de requisitos. Queda claro (tanto para el equipo como para el usuario) que la fecha de la demo es cuando debe estar el producto estable, que hasta entonces sólo estará viendo una versión en desarrollo.

En teoría todo pinta bien, ya veremos en la práctica :)

Redes Sociales (I): el arranque en frío

2009-02-15T13:27:00.003Z

Las redes sociales basan su funcionamiento en el comportamiento de las personas que las conforman, y, como sistema humano que son, presentan ciertos fenómenos más o menos indeseables.
Uno de ellos es el fenómeno del arranque en frío. En general se refiere a que, dada una situación inicial de un sistema o un elemento (en función del contexto el significado de inicial varía), su estado posee una gran inercia, por lo que es difícil que comience a funcionar.
Esta propiedad, como otras tantas cosas en informática, puede verse a muchos niveles. La aplicación más amplia puede ser el arranque en frío de la red en sí misma: por lo que sea planificas la creación de una nueva red social -justo lo que el mundo necesita-, pero al no tener usuarios los usuarios no se registran, en forma de problema recursivo. El éxito de una red social es el uso que de ella den los usuarios y sus interacciones, por lo que, al estar vacía, tiene poco valor.
Se proponen varias soluciones:

Por supuesto, haz algo que tenga interés.
Establece mecanismos que recompensen la creación de contenidos.
Proporciona APIs de forma que los usuarios puedan extender y conectar el sistema.
Alimenta tu sitio a través de APIs y enlaces de otros sitios. Una utilidad muy importante es la de importar contactos. Nadie a estas alturas de la vida se planteará introducir de nuevo las direcciones de sus amigos a mano.
Maximiza la visibilidad social del contenido creado por los usuarios.
No generes spam.
Permanece atento a los usuarios y añade nueva funcionalidad con frecuencia.

Yo añadiría otras:

Ofrece contenido desde el principio de su apertura "pública". Mediante un conjunto de "usuarios expertos" puedes crear contenido de forma que cuando el sitio "abra" ya esté funcionando.
Haz que los usuarios quieran registrarse. Uno de los aciertos que han llevado al éxito a Tuenti ha sido el sistema de invitaciones, creando una sensación de exclusividad que hace que la gente quiera estar. Es otra de las motivaciones del "beta" ya generalizado en los "servicios 2.0".

Si nos "acercamos", encontramos un nuevo caso de problema de "arranque en frío": el de el contenido nuevo. La primera vez que leí al respecto fue referido a last.fm, el servicio en el que los usuarios envían sus preferencias musicales. El problema es, esencialmente, que hay contenido que parte con tanta ventaja (Los Beatles, Rolling, Radiohead, Coldplay...) que es difícil que el nuevo cobre relevancia. Yo lo notaba con la característica de "reproducir artistas similares" del magno reproductor Amarok. Pusiese lo que pusiese, a eso de una o dos horas los Beatles o los Rolling hacían de agujero negro: al final el contenido que suena acaba estando relacionado con ellos, y se convierten en lo único que reproduce el sistema.
Este problema es difícil de combatir por su propia esencia. De hecho, alguno podría discutir que no se debe combatir, y que el éxito del contenido de una red no debe estar manipulado. Si las fotos de rosiehardy son tan buenas, ¿por qué no debe estar abonada a la portada del explore?
Como para todo, hay soluciones, al menos parciales:

Introducir aleatoriedad para evitar los "agujeros negros". Esta es la estrategia del nuevo Amarok. Han complicado la lista dinámica de forma que sea posible "escapar" de esos artistas destacados.
Creación de listas específicas que favorezcan las novedades: listas de "lo más nuevo", "lo más escuchado en los últimos días", etc.
No crear elementos que penalicen aún más el arranque en frío. Por ejemplo, en el concurso de fotografía de Público han creado una página de 'las más votadas'. Esto es muy negativo, porque los usuarios casuales entrarán a ver lo que hay e irán a esa página en vez de recorrer la galería entera, lógicamente, favoreciendo el voto de las más votadas. Existiendo algo así se premia rapidez en la carga y en el posicionamiento inicial en vez de la calidad en sí. Yo lo sufrí la semana pasada, esta estoy intentando hacer lo contrario :).

Estrategias motivadoras 'alternativas'

2009-02-12T16:23:00.004Z

Mi pareja lleva una agencia de viajes Ecuador en Valladolid (enlace patrocinado ;) ) y hoy me contaba que en uno de los cursos a los que va a ir son muy dados a hacer que la gente participe a base de premios. Cuando alguien responde una pregunta, le dan un detalle (un imán o similar). Obviamente el "premio" no es la finalidad, ni del curso ni de los asistentes, pero convierten algo que normalmente es aburrido y unidireccional en algo más divertido y, sobre todo, más participativo.
Siempre habrá alguno que diga que esto es algo estúpido e incluso una falta de respeto, poco profesional, que es como las sardinas de las focas o los plátanos de los monos... ¿Vosotros lo veis así? Yo no. Ojo, sólo hablo de premios "alternativos", no incentivos "de verdad" (económicos o, en general, caros, eso es tema para otro post).
En mi opinión, estos premios alternativos son más que un juego, que permite establecer una relación de confianza mayor. Los resultados son claros: más gente va al curso, la que va se lo pasa mejor, y además, participa.

¿Incentivos como estos son aplicables a la gestión de proyectos o, en general, a una empresa de desarrollo de software? No hablo de algo que vaya a aumentar la productividad de forma generalizada o una nueva bala de plata, sólo algo positivo, de escasa importancia. Últimamente estoy teniendo que dar más charlas de las que me gustaría, y noto que son bastante pesadas. Hago lo posible por mejorar la participación, pero no es fácil. Incluso el trabajo diario se podría intentar hacer algo más ameno (sí, ya sé que es trabajo, y sí, sé que no somos niños y no hay por qué convertir todo en un juego, pero a nadie le amarga un dulce).
Alguno hay ya en marcha: para Hudson, el sistema de integración contínua, hay un plugin que se llama "El Juego de la Integración Contínua". En resumidas cuentas, se dan puntos por "hacer las cosas bien": añadir pruebas, participar en compilaciones correctas, mejorar las métricas de calidad... Yo lo he instalado en nuestro servidor, en unas semanas os diré cuál es el balance.
Obviaremos el sistema de logros para Eclipse ;)
No se necesita nada tecnológicamente elevado, con una caja de cartón puede valer. Un par de personas en el anterior despacho hicimos una hucha de fails, cada vez que cometíamos una burrada poníamos 10 céntimos.

¿Qué opináis? ¿Tenéis trucos para hacer vuestras exposiciones más llevaderas? ¿Y en el trabajo?

Resolución de problemas

2009-02-08T19:06:00.003Z

Uno de los indicadores más claros, en mi opinión, de la validez (aptitud y actitud, principalmente) de alguien en un trabajo es la forma en la que afronta un problema. Por ejemplo, plantear un problema en una aplicación web en una entrevista de trabajo, puede permitir conocer muchas cosas del entrevistado:

¿Comprende el modelo cliente/servidor? No sería la primera vez que escucho a gente que no comprende dónde se ejecuta el PHP y dónde el Javascript.
¿Es capaz de leer los errores? Lejos quedan aquellos volcados típicos de ensamblador o C. Los lenguajes y los entornos de hoy suelen dar información significativa de lo que ocurre cuando hay un problema. Sin embargo, no todo el mundo realmente se para a interpretarlo.
¿Está acostumbrado a programar tests? Hoy en día se puede probar casi todo, desde el acceso a datos hasta problemas de interfaz. Sugerir programar una prueba cuando aparece un problema sería un muy buen síntoma.
¿Tiene recursos? Pensar en problemas frecuentes o ofrecer alternativas de solución suelen ir relacionado con experiencia real.

Cuando alguien me pide ayuda y su discurso está plagado de "no sé", "esto debería funcionar", "antes iba bien", tiemblo, y si encima se remata con un "no, no he probado eso" o "espera que miro qué pone el error", directamente se me cae el alma a los pies. Es habitual decir que un ingeniero se dedica a resolver problemas. Viendo la ineptitud que a veces presentamos para hacerlo, no me extraña que nadie considere la Informática una Ingeniería.

Me encantan 'C.S.I.' y 'House'. Ambas tienen en común que el leitmotiv es la resolución de un problema. La primera se centra en la recopilación de pruebas, mientras que la segunda es sobre investigación del problema en sí y prueba y error. De hecho, ofrecen dos perspectivas diferentes de cómo afrontar un problema:

En C.S.I. es necesario ser muy meticuloso y seguir unos protocolos establecidos (por temas legales) y se dispone de una cantidad razonablemente alta de recursos (un departamento, helicópteros, alta tecnología...). No se presupone nada. Se recopilan y analizan pruebas, y cuando surge una hipótesis se deben conseguir hechos que lo contrasten. Si no se hace así, el señor juez dejará libre al malo por no validez del proceso. La ventaja de esta aproximación es que, con tiempo, la verdad suele salir a la luz por sí misma: el mismo proceso de recopilación de pruebas te lleva al asesino, no hay crimen perfécto (¿o sí?). Ellos tienen el agravante de que su problema (el malo) sigue corriendo mientras ellos avanzan.
En House se suele trabajar con prisas (el paciente se muere cada vez más rápido) una cantidad limitada de recursos (no puedes dedicar todo el hospital para un paciente) pero muy buenos (tiene un equipo de los mejores profesionales). Hay procedimientos, sí, pero los protagonistas suelen estar por encima de ellos, considerando como único protocolo el conseguir que el paciente no muera. Mediante diagnóstico diferencial, similar al método socrático, y un (exagerado) proceso de prueba y error se genera el conocimiento que permite localizar el problema.

En mi opinión en informática la resolución de errores se asemeja a House. Cuando encuentras un fallo (aparece un síntoma), hay que...

Pensar posibles lugares problemáticos (posibles enfermedades): ¿problema de configuración del servidor? ¿Fallo en la lógica de negocio? ¿Problema con el acceso a datos?
Hacer los análisis no costosos ni intrusivos: "¿está enchufado?" "¿El usuario y password son correctos?" "¿La base de datos está levantada?".
Priorizar (por probabilidad y coste) los problemas posibles, y comenzar la prueba y error. Nota: quita el tratamiento después de cada prueba (deja el código como estaba).

A éstos añadiría un punto 0 que no encaja en la analogía: prepara una prueba que primero demuestre que hay un problema, y que después te sirva para demostrar que lo has resuelto.

¿Los usuarios a la tecnología o la tecnología a los usuarios?

2009-02-08T13:15:00.002Z

Hace un mes abría una incidencia con Orange porque la velocidad de sincronización me había bajado aproximadamente a la mitad. El otro día me llamaban para cerrar la incidencia, indicándome que la culpa sería de Telefónica, que habría venido más ADSLs en la zona, por lo que la velocidad se reduce. Intenté no pagar mi indignación con la pobre señorita del teléfono, pero hay varias cosas que claman al cielo...

¿A mí que me cuentas de Telefónica? Yo tengo contrato con Orange (incluso la línea), y una de las razones para cambiar a vuestro ADSL fue tener "un único pagador" (cuando tenía problemas antes se pasaban la patata caliente).
¿Cómo que porque haya más clientes se baja la velocidad? ¿Si mi vecino abre el grifo yo no me puedo duchar? ¡Estáis vendiendo por encima de la capacidad!

Dejemos al margen mis problemas con Orange. En Nubeblog enlazaron, casi coincidiendo con lo anterior, unos datos sobre que las PYMES pasan (sic) del Cloud Computing.
Estos dos hechos me llevaron a una discusión filosófica (soy mucho de filosofar contra mí mismo). ¿Cuántos detalles técnicos debe conocer un usuario?

¿Para qué quiere una PYME saber qué es el Cloud Computing? ¿Para qué quiero yo saber que mi problema es porque tienes malas condiciones respecto a la reventa de la línea? Dime que me vas a hacer un backup a través de Internet a un 10% de mi coste actual. Dime que no se puede ofrecer un servicio de más calidad en mis condiciones y ofréceme otra oferta... Ahorrate lo demás, ¡no me importa!

Haz buenos productos sin entrar en tecnicismos y detalles que no le aportan nada al usuario. Lo demás es autobombo (o excusas).

X enlaces de los X últimos días

2009-02-01T17:54:00.003Z

Unas cuantas cosas de las que he compartido en Google Reader en los últimos días.

¿Tu informático está trabajando?
Estados mentales de un informático, desde el 100% improductivo hasta el flow.

Seven Principles of Lean Software Developement
La semillita que papá puso en mamá para dejar de parchear el desarrollo en cascada mediante desarrollo por contratos, de la cual salieron las metodologías ágiles.

Salesforce.com Agile Transformation
Soy un adicto de los casos reales. Aquí vemos cómo Salesforce.com adoptó metodologías ágiles.

Can You Cure the Copy/Paste Disease?
Sí, sé que sufro micromanagementitis, pero nunca dejaré de amenazar con cortar dedos a quien cortapegue, y me gustan los artículos que me dan la razón (soy así :) ).

Agile in the Trenches
Más casos reales. Creo que un caso así demuestra la utilidad, a veces puesta en duda, de un Scrum Master.

OFFTOPIC: Que llueva, que llueva
La convivencia en pareja trajo consigo una negociación en la que intercambiamos los gorgoritos de los triunfitos por las carreras de Alonso, los Nadal - Federer, y unos cuantos tuercebotas. Dicho sin prosa, a cambio de ver deporte sin discutir, durante unos meses al año tengo que soportar Operación Triunfo.
El programa en sí no es tan terrible. El esfuerzo de la música en directo no es habitual en televisión estos días, y que todos, participantes e invitados, interpreten en directo, es bueno. Y siempre hay alguno que canta bien, eso es así. Además la música de fondo siempre es muy buena (en el último año escuché Muse, Coldplay, Los Planetas, Arcade Fire...), ya sólo queda que promocionen esa en vez del último hit de Vale Music. No me gusta el lado reality, pero, por encima de todo, me disgusta la idiotización musical que este programa ha producido. En los últimos castings se hacía patente: la mayor parte de los adolescentes que engordaban las infinitas colas de candidatos habían vivido sólo con Operación Triunfo. Cuando se les ponía a prueba con una canción no conocían la versión original, sino la del anterior triunfito. Se piensan que triunfar es salir de ese programa. Dadme a un currante de garitos madrileños como Luis Ramiro, Marwan o Andrés Lewin, y retirad del mercado los clones prefabricados.
Al grano, que me voy por las ramas.
En las últimas ediciones el principal interés pasó del escenario al jurado, a Risto Mejide. Tengo que admitir que, como el 90% de la audiencia, disfruto sus minutos como un niño. Su personaje de publicista hiriente y odioso me encanta, pero lo que se puede ver más allá me parece también del máximo interés. Más allá de su fachada, nos ha dejado estos días un artículo directo, sincero y, en mi opinión, terriblemente acertado. Quien quiera estancarse en la mediocridad y dejarse llevar por el torrente de la crisis, que lo haga. Pero que no venga luego lloriqueando.

Programación Basada en Google
Desconozco si Julio César Pérez figura en esas listas de gurús, pero su blog me encanta. Pocas entradas, pero admirablemente escritas, y siempre de valor. En general es un tipo práctico (atajos de Eclipse, ejemplos de código...) pero esta vez hace una reflexión muy acertada sobre un antipatrón de desarrollo que todos reconocemos.

Micromanagement

2009-01-29T19:29:00.004Z

Hoy he caído por casualidad en una tira sobre micromanagement en Geek Hero Comic:

Está claro que esta tira no es Sinergia Sin Control, pero me ha hecho pararme a pensar si tengo un problema: me he visto reflejado con el tipo del peinado de el de Simply Red (o el Actor Secundario Bob, o Bisbal, o mi amigo Valle ^_^).
Tengo que admitir que soy muy maniático con muchos detalles que considero importantes, y, más que importantes, malos síntomas. Hoy mismo, en una presentación sobre metodología de desarrollo que he hecho para los compañeros, me he declarado un entrometido maniático, y les he pedido disculpas por anticipado al respecto.
Concretamente, soy MUY maniático con estos detalles (entre otros), que si seguís el blog ya habréis visto comentados:

Programar usando el ratón en vez de dominar (progresivamente) los atajos de teclado.
No aprovechar las vistas de Eclipse, en sus diferentes variantes: ordenar el código mediante algún criterio en vez de utilizar la vista 'outline'; no utilizar //TODOs y //FIXME para que aparezcan en Tasks; no explotar las posibilidades de la depuración...
¡Cortapegar!
Nomenclatura de variables.
...

Buscando al respecto del micromanagement he encontrado diversas opiniones y descripciones. En general se puede definir como gestionar intentando controlar todos los detalles, hasta el más pequeño, sin capacidad de delegación o de confianza.
Tengo que admitir que me siento bastante representado en unos cuantos puntos (la Wikipedia lo asocia a desórdenes obsesivos compulsivos, no sé si diría que tanto, pero casi), así que debo reconocer mi errores al respecto (alguno ciertamente grave). En mi defensa, diré que mi intención siempre fue intentar ayudar, pero está claro que no siempre fue de forma correcta.
Prometo esforzarme en mejorar :).
Una vez hecho este ejercicio de autocrítica...

¿Dónde está la barrera que separa el micromanagement del management y del mentoring? Parece claro que los tres son prácticas relacionadas. Diría incluso que el micromanagement es la perversión de la unión de los otros dos, es llevarlos al extremo. Pero ¿dónde comienza uno y empieza el otro? Creo que es algo subjetivo, que depende de los implicados. Lo que a una persona le puede parecer una ayuda, una sugerencia, a otro le puede parecer un entrometimiento. Seguramente llegar al punto de la confrontación es un síntoma, pero hay otros, como la falta de percepción de confianza, que no son tan fáciles de ver.

Sin embargo, ¿no son herramientas como Checkstyle una forma de micromanagement? ¿No lo es el Daily Scrum? Yo los veo como herramientas para mejorar la calidad del producto y uno mismo, pero esa es mi percepción...

¿Qué opináis? ¿Microgestionais? ¿Lo habéis sufrido alguna vez? ¿Creéis que con ciertas personas o en ciertos momentos puede ser necesario adoptar posturas así? ¿Cómo lo evitaríais?

Supongo que, como siempre, in medio stat virtus.

P.D.: a los compañeros que leáis esto, no dudéis en atarme en corto en este aspecto ;)

Trazabilidad

2009-01-25T20:11:00.002Z

Podríamos explicar la trazabilidad (bidireccional) en el contexto del desarrollo de software como "dado un requisito llegar a la línea de código que lo implementa, y al contrario, dada una línea, saber con qué requisitos corresponde"(a grandes rasgos, no cortapegéis esto para nada importante ;) ).
Esto tiene muchos matices y complicaciones, tanto teóricas como prácticas. ¿Realmente es importante? ¿Necesitamos bidireccionalidad? La trazabilidad es claramente una función no biyectiva: una misma línea probablemente corresponde con varios requisitos, y un requisito corresponde con muchos fragmentos de código dispersos.
Hasta hace poco siempre había visto esto como algo imposible de conseguir -a un coste razonable-. Los requisitos se registraban en un procesador de textos, las tareas en un diagrama de Gantt, y el código en un repositorio, todo desconectado. Los intentos que ví para solucionar esto eran añadir funcionalidad a estas herramientas para lograr lo que se necesitaba. Por ejemplo, hay (caros) plugins para Word que añaden "orientación a requisitos", permitiendo, por ejemplo, versionarlos. En las tareas del Project habría que meter los códigos de los requisitos. En los commits de código, los códigos de las tareas... Trabajo, trabajo, trabajo. Al final, se abandonaba.
El problema era de planteamiento. Es inutil forzar el uso de herramientas para un fin ajeno a los objetivos del implicado: al programador no le da ningún beneficio el esfuerzo extra de añadir el código de la tarea. Al analista, el uso de herramientas más complejas que el word le supone también más trabajo. El gestor del proyecto probablemente no tiene ni tiempo ni ganas de actualizar o comprobar el diagrama de gantt...
La solución ha venido de forma conjunta a la adopción de técnicas ágiles y el cambio de herramientas integradas. Las tareas se añaden en el gestor de incidencias (Trac en nuestro caso). Esto, de paso, soluciona el problema del versionado. Además, al ser información estructurada, al estar en una base de datos, se pueden generar informes y vistas en función de las necesidades. Al programador se le da el Eclipse con Mylyn, que le da valor añadido. Indicar la tarea en la que está trabajando no sólo no es trabajo (hacer un click en ella), sino que le aporta valor añadido, ya que el entorno recuerda el contexto (la perspectiva, las vistas, los ficheros abiertos...), haciéndole más fácil alternar entre tareas. Al final, en el gestor tenemos los requisitos (con su histórico) y podemos ver el código relacionado.

¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.

Calidad de Código

2009-01-24T11:55:00.003Z

Practiques Integración Contínua o no, creo que tus scripts de compilación deberían ejecutar también unas cuantas herramientas de calidad de código. En mi opinión este tipo de herramientas es útil tanto para controlar (y mejorar) la calidad del código en sí como para formar al equipo en una mentalidad de mejora contínua.
Yo acabo de integrar las siguientes (y la lista probablemente siga aumentando):

A esto hay que añadir que Hudson integra también el seguimiento de las tareas abiertas (TODOSs, FIXMEs, etc) que también es fundamental.

¿Qué otras herramientas utilizáis?

Informática Corporativa

2009-01-20T21:56:00.002Z

En muchas organizaciones, y muy notablemente en la Administración, se viene creando un departamento (o movimiento, o tendencia, o normativa...) de "Informática Corporativa". Procede de que la organización crece horizontalmente y la informática, que es transversal (ya que afecta y se desarrolla en todos los departamentos), se vuelve heterogénea en la organización. Esta heterogeneidad es vista como algo negativo, ya que en apariencia aumenta los costes:

El personal es menos flexible, ya que un especialista en la tecnología de un departamento puede no serlo para otro.
Los recursos hardware son menos versátiles, ya que las aplicaciones desarrolladas en un departamento no son desplegables en otro.

Para dar forma a esta informática corporativa se establecen unos procedimientos (casi siempre a medida, síndrome NIH) que dan lugar a una arquitectura común para los desarrollos.
Esto, visto desde el punto de vista funcional, desde la organización se pretende interpretar como algo fantástico: durante uno o dos (o más) años estudiamos las tecnologías disponibles, para seleccionar la más mejor, especializarnos en ella, y utilizarla para todo.
En la práctica, lo que sucede es que las organizaciones tardan dos años en seleccionar una tecnología que ya está obsoleta para cuando se implanta por primera vez, y se pelea contra ella durante años. Los errores cometidos durante el estudio (todos nos equivocamos) en vez de solventarse se parchean, para mantenerse de forma supuestamente ortodoxa en la normativa. El personal de toda la organización se especializa (en el mejor de los casos) en herramientas que carecen de interés en muy poco tiempo, y se estancan en ellas. Por tanto, todo intento de cambio se percibe como una amenaza, una intromisión en su trabajo. Además, como la arquitectura se convierte en normativa, se prohíbe la instalación en la red interna de todo aquello que se salga de ella.
La informática cambia con mucha frecuencia. Y, aunque no cambiase, no hay balas de plata. Intentar hacer norma de una tecnología es una locura: no hay nada que sirva para todo (ni en metodologías ni en herramientas) y lo menos malo para todo lo es hoy pero no mañana.

No me gusta señalar problemas sin proponer alternativas. ¿Solución? Normaliza el cambio:

Establece una política de formación que permita que la gente no sólo se recicle periódicamente, sino que también evolucione constantemente.
Haz una revisión tras cada proyecto para analizar los puntos positivos y negativos.
Haz un estudio de viabilidad real, en el que de verdad se estudien alternativas de implementación.

El cambio es bueno. ¡Esto no significa que cada mes tengas que hacer las cosas de forma diferente! Si tienes gente formada, y haces un estudio de viabilidad real, el cambio surgirá de forma progresiva y natural: se irán incorporando cosas nuevas, se sustituirán componentes mejorables... Incluso los "cambios radicales" (piensa en un primer proyecto con Python en vez de J2EE) parecerán normales, ya que, en el fondo, los conceptos son los mismos.

PD: mañana tengo que trabajar en mostrar que un cambio es positivo, ¡deseadme suerte! ;)

X enlaces de esta semana

2009-01-18T11:49:00.003Z

Unas cuantas cosas que me han llamado la atención esta semana:

La LOPD y el Cloud Computing

Interesante artículo sobre las implicaciones legales de externalizar los datos.

100 Interview Questions for Software Developers

Preguntas que debes hacer (o para las que te debes preparar) en una entrevista de trabajo.

Getting ready for the cloud

Desplegar una aplicación Java existente en Amazon EC2.

Buenas prácticas: Tratamiento de Excepciones

2009-01-13T16:04:00.003Z

Entrada rápida que resume algo que ya he escrito en otros sitios, y que me gustaría tener público (¡y recibir comentarios!).

Criterios a tener en cuenta al tratar excepciones en Java:

Es mejor que la aplicación falle a no saber que ha fallado (y qué ha fallado). Corolario: si no vas a tratar una excepción correctamente, mejor no hagas nada y que la aplicación falle.
Siempre que se produzca un error en la aplicación tiene que haber información sobre el error en pantalla, al menos indicando que se ha producido un error. Corolario: no te limites a trazar el error en el log, ¡no siempre habrá alguien mirando!
No traces mediante System.out o System.err, utiliza un sistema de logging.
Si sólo vas a relanzar la excepción, no la relances, haz que el método lance ese tipo de excepción.
No loguees y relances constantemente, no es necesario. Los únicos puntos que no deben lanzar excepciones son los métodos invocados directamente por la aplicación, para que no le llegue al navegador la traza del error. Y si utilizas un framework que gestione bien las excepciones (como Seam), incluso puedes saltarte esta norma.
Cuando escribas en el log, escribe información significativa, como los parámetros recibidos por el método. Lo trivial (el nombre del método, por ejemplo) ya se verá en la traza.
Al trazar, no concatenes el mensaje de la excepción, vuelca la excepción en sí (toda la traza).
Un método no debería declararse como throws Exception, ya que enmascara todas las excepciones, sin permitir gestionar el error concreto. No pasa nada, por ejemplo, por que lance varias: throws IOException, MiOtraException. De esta forma, el que la invoque sabrá a qué tipos de error se debe enfrentar.

Contraejemplos (ejemplos de cómo no se deben hacer las cosas):

} catch(Exception e) { }; : se ocultan los errores, es imposible saber qué ocurre.
} catch(Exception e) { System.err.println(e) }; : estamos trazando en err, ni se ve nada en pantalla ni en el log, así que en explotación no sabremos qué ocurre.
} catch(Exception e) { log.debug("Ha ocurrido algo malo: "+e); }; : el nivel de log es incorrecto (debería ser error), no se dan datos sobre el error, estamos concatenando la excepción, no estamos relanzando...
} catch(Exception e) { log.error(e) }; : no se dan datos sobre el error, y no estamos lanzando nada, así que en pantalla no se verán los errores.

Ejemplos válidos en otras circunstancias:

} catch(Exception e) { log.error("Identificador: "+id, e); throw new MiExcepcion(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, lanzamos una excepción (que contiene la provocada, para no perder traza) para que el nivel superior pueda seguir tratando el error. Esto sería incorrecto, de todas formas, si en nuestro sistema esto vuelca la traza en el interfaz de usuario. Aparte, probablemente incluso sea innecesario hacer esto (ver último ejemplo correcto).
} catch(Exception e) { log.error("Identificador: "+id, e); anhadirMensajeDeErrorAlUsuario(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, mostramos un mensaje de error en pantalla. Esto sería incorrecto, de todas formas, si este método es invocado por un nivel que necesita procesar el error específicamente.
...) throws IOException : si el método no va a hacer nada interesante con la excepción, ¿para qué capturarla?

Actualización 0901131738: este es un tema del que se pueden encontrar infinidad de fuentes, como en java.net, con más detalle, en inglés.

Dos enlaces de esta semana

2009-01-11T09:40:00.002Z

Uno de morralla comercial y otro de programación:

SOA ha muerto. Larga vida a los servicios

¿Qué significa "SOA ha muerto"? ¡Nada! Lo único que consiguen grupos como Burton con declaraciones como estas es cambiar las conversaciones de enteradillos que los directivos que no saben de qué están hablando mantienen entre reuniones. Igual, siendo malpensado, consiguen también redirigir inversiones: ya han conseguido vender su consultoría acerca de SOA, ahora tienen que conseguir vender otra, y ya sabemos que este es el año del Cloud Computing...

Lead developer, Are Yoy Mentoring?

Un buen artículo sobre cómo reintegrar a un programador negativo. En vez de quejarse, tener iniciativa, preguntarle, utilizar herramientas de análisis estático...

Introducción a Seam

2009-01-08T22:19:00.002Z

Como apoyo para una próxima sesión de formación he preparado una modesta presentación/resumen de lo que es Seam, muy por encima. Las principales fuentes son el manual de referencia y "Seam in Action", así que si quieres conocerlo en profundidad, nada como las fuentes originales, mucho más detalladas y sin mis gazapos (ni tonterías de mi cosecha ni relación con trabajo previo mío).

Reseña: Peopleware

2009-01-04T17:40:00.016Z

Peopleware es otro de esos clásicos que todos los informáticos deberíamos leer. Es un libro atípico, porque habla de la Ingeniería del Software en términos de personas, sentimientos, emociones...

A continuación, la tabla de contenidos con el argumento de cada capítulo.

Contenido del libro
Parte I: La gestión del recurso humano
El software lo desarrollan personas, no máquinas, adecuemonos a eso.
Capítulo 1: En algún lugar, en este momento, un proyecto va a fracasar
Los proyectos software fracasan, principalmente, por cuestiones sociológicas, no técnicas.
Capítulo 2: Haz una hamburguesa de queso, vende una hamburguesa de queso
El desarrollo de software es inherentemente diferente de la producción (industrial). Es un error aplicar técnicas de producción (pensar en las personas como máquinas) al desarrollo.
Capítulo 3: Vienna waits for you
(Dejo el nombre del capítulo en inglés por ser un extracto de una canción de Billy Joel, 'Stranger'.)
Más horas de trabajo no implica ni más ni mejor trabajo, para las personas el trabajo no es lo más importante. La adicción al trabajo sí es un problema.
Capítulo 4: Calidad - si el tiempo lo permite
Comprometer la calidad no es una buena estrategia: mina la auto
estima de la gente. De hecho, a la larga una mayor calidad redunda también en una mayor productividad.
Capítulo 5: Revisión a la Ley de Párkinson
No es cierto que el trabajo de desarrollo se expanda hasta abarcar todo el tiempo disponible para él.
Capítulo 6: Laetril
No existen los remedios mágicos ni las soluciones que multiplican la productividad.

Parte II: El entorno de la oficina
Factores externos a las personas que afectan a la productividad.
Capítulo 7: La política de mobiliario
Las políticas de mobiliario no parecen estar pensadas en pro de las personas (y, por tanto, tampoco de su productividad).
Capítulo 8: "Es imposible hacer nada aquí de 9 a 5"
Factores como el ruido o el espacio están más correlacionados con la productividad que la experiencia o el lenguaje de programación.

El capítulo 8 expone datos muy interesantes sobre un estudio que los autores han realizado durante años. Dan un ejercicio a dos candidatos de cientos de empresas, y relacionan los resultados con factores ambientales.

Capítulo 9: Ahorrar dinero con el espacio
La cantidad y calidad del espacio para el trabajador es fundamental.
Interludio: Medición de la productividad y OVNIs
Medir la productividad es difícil, pero puedes medir algo que al menos te permita saber tu posición respecto a la competencia.
Capítulo 10: Tiempo mental contra tiempo de cuerpo presente
Para que el tiempo se aproveche al máximo el cerebro debe entrar en un estado llamado "de flujo", al que cuesta llegar pero del que es muy fácil salir por culpa de interrupciones. Para maximizar la productividad hay que maximizar la proporción de "tiempo de flujo" respecto al "tiempo de cuerpo presente".
Capítulo 11: El teléfono
Un mundo sin teléfono sería algo fantástico, pero como no parece posible, hay que conseguir minimizar el impacto de las llamadas: silenciar el timbre (o al menos bajar el volumen), utilizar sistemas alternativos, etc.
Capítulo 12: El retorno de la puerta
El entorno de oficina tradicional, de dos, tres o cuatro personas, con paredes y puertas, se ha perdido, equivocadamente, en favor de entornos diáfanos, con mucho ruido y sin privacidad.

En este capítulo se expone un interesante estudio sobre la música y el trabajo. Si bien la parte lógica/matemática del trabajo no se ve afectada, la parte creativa se ve anulada si estas escuchando música.

Capítulo 13: Realizando pasos de paraguas
Nota: para los curiosos, podéis consultar el significado de 'paso de paraguas' ('umbrella step'), que no tiene traducción directa.
En este capítulo se exponen varios conceptos de arquitectura y decoración de interiores para hacer un mejor entorno de trabajo: situación de las ventanas, de los muros, de los espacios compartidos... El resumen más correcto, aunque impreciso, sería decir que "hay que construir como se lleva haciendo desde hace miles de años".

Parte III: La gente correcta
Cómo (y por qué) conseguir a los mejores, mantenerlos, y aprovecharlos al máximo.
Capítulo 14: El factor Hornblower
Nota: 'Hornblower' aquí se refiere a Horatio Hornblower, protagonista de una serie de novelas de C.S.Forrester sobre las guerras napoleónicas.
La gente es diferente, y eso es bueno. No hay que potenciar la similitud y la entropía, sino todo lo contrario. A menor entropía (entendida como igualdad), más trabajo hecho.
Capítulo 15: Contratar un malabarista
En las entrevistas de trabajo no basta con preguntar a los candidatos, hay que ver sus habilidades en la práctica.
Capítulo 16: Feliz de estar aquí
El coste de la rotación es muy elevado (más de 5 meses de trabajo), hay que conseguir ~~mantener a la gente~~ que la gente quiera quedarse.
Capítulo 17: Sistema autoreparable
Cuando se automatiza un sistema humano, por ejemplo al aplicar una Metodología, se pierde gran parte del valor humano. Concretamente, cuando el valor de una Metodología es hacer algo uniforme, mejor sería conseguirlo mediante formación, herramientas, y revisión por parejas.

Parte IV: Crecer equipos productivos
Nota: he traducido 'growing' como 'crecer', aunque no suene demasiado bien, para mantener la metáfora agrícola.
Ya tienes la gente, ahora tienes que hacerla trabajar en equipo.
Capítulo 18: El todo es más que la suma de las partes
Tienes que conseguir hacer que el equipo esté totalmente cohesionado en pos de un fin común.
Capítulo 19: El Black Team
El Black Team es el paradigma de equipo cohesionado. Fue un equipo de testers de IBM, temido por los desarrolladores por su eficacia, aún cuando todo el equipo inicial había cambiado.
Capítulo 20: "Equipocidio"
No es fácil determinar qué debes hacer para conseguir un gran equipo, pero sí hay varias cosas que no debes hacer: gestión defensiva, burocracia, separación física, fragmentar el tiempo de la gente, reducir la calidad del producto, establecer hitos imposibles y control de camarilla.
Capítulo 21: Cena de espagueti
El mejor jefe es aquel que consigue gestionar sin que parezca que hace nada.
Capítulo 22: Open Kimono
La mejor gestión es aquella en la que se confía plenamente en los miembros del equipo y en la que la autoridad se ejerce de forma natural, no mediante imposiciones.
Capítulo 23: Química para la formación de equipos
Para que una organización siga una estrategia correcta de formación de equipos, debe cuidar lo siguiente: culto a la calidad; proporcionar realimentación positiva; sentimiento de élite; alentar la heterogeneidad; preservar los equipos exitosos; proporcionar dirección estratégica, no táctica.

Parte V: Debería ser divertido trabajar aquí
El trabajo no debería ser algo aburrido, una carga, algo negativo... Debería ser divertido, interesante, enriquecedor...
Capítulo 24: Caos y orden
La tendencia natural en el trabajo es ir hacia el orden, pero introducir deliberadamente elementos novedosos, aumentando el caos, disminuyendo así la entropía, es positivo.
Capítulo 25: Electrones libres
Hay gente que no encaja en puestos específicos, pero que aportan gran valor a la empresa. No siempre es necesario regirse por estrictas jerarquías.
Capítulo 26: Holgar Dansk
Introducir los cambios parte de la iniciativa individual. Si algo es sensato, hazlo, que será más fácil de lo esperado, encontrarás ayuda.

Valoración personal
Peopleware es un libro excepcional. No se limita a obviedades, y no se limita a exponer problemas. Entra en muchos temas en profundidad, incluso aportando datos concretos, y aporta soluciones (por ejemplo, enumerando alternativas al uso de Metodologías). Es un libro imprescindible, que nunca envejecerá, y útil no sólo para jefes. Provocador y agitador a todos los niveles. Hay muchísimas cosas aplicables constantemente. Yo ya me estoy haciendo una lista...

WTF como ejercicios en entrevistas y en formación

2009-01-03T08:28:00.004Z

A estas alturas del año ya habréis visto el código responsable del cuelgue masivo de los Zune:

    while (days > 365) {
     if (IsLeapYear(year)) {
        if (days > 366) {                
         days -= 366;
         year += 1;
       }
     } else {
       days -= 365;
       year += 1;
     }
   }

Este código no creo que entre en la categoría de WTFs, a todo el mundo se le puede patinar un igual. Sin embargo, me viene de perlas para uno de los trabajos que voy a tener en los próximos días: preparar ejercicios de programación para formación y contratación (¿por qué será que recruiting me parece más preciso?). En un post anterior en el que hablaba de mi opinión sobre la aptitud y actitud profesional, Julio César Pérez comentaba lo siguiente

La pregunta estrella era implementar una funcion recursiva que calculara el factorial de un numero entero en cualquier lenguaje. Sólo el 10% la hicieron bien y todos los candidatos eran como mínimo ingenieros.

Ya me habían mirado raro a veces por opinar que las entrevistas hay que orientarlas en ese sentido, pero desde que supe que Google pide programar en una pizarra me he sentido reafirmado: las entrevistas deben ser prácticas.

Contexto
Trabajo en un entorno parcialmente universitario, por lo que una de nuestras razones de ser es la ocupación de estudiantes, con las ventajas e inconvenientes que esto conlleva.

Requisitos
Necesito una forma de...

poder evaluar en una entrevista de trabajo los conocimientos (si hablamos de gente con experiencia) o la aptitud (si hablamos de becas) de una persona.
facilitar la autoformación del personal, nuevo o no, que se va a incorporar a proyectos con nuevas tecnologías.

Alternativas de implementación

Para las entrevistas, recopilar una serie de WTFs y trozos de código, tanto correctos como no, y preguntar al entrevistado por ellos.
Para la formación, plantear ejercicios cortos con tareas de no más de una o dos horas, en el que se busque escribir código lo más impecablemente posible. Una vez completado el ejercicio, alguien revisaría el código escrito para pulir entre los dos todo lo mejorable.

Esto último de la revisión, aunque algo exigente (ocupa a dos personas en código de prueba) me parece fundamental. En mi opinión, pensar que una persona aprende a programar símplemente programando es falso. Conozco gente que programa mal y lo seguirá haciendo toda su vida, porque ni lee código de otros, ni libros, y nadie le corrige sus errores. Especialmente en entornos de formación, la figura del revisor me parece fundamental.

Calidad de código en el motor de integración contínua como formación: tanto instalar plugins de Eclipse como generar informes de calidad de código pueden ser positivos para aprender. Si se presta atención a los warnings de FindBugs, PMD o Metrics se puede aprender mucho (¡a la vez que mejoras la calidad!).

PD: aquí, al hablar de "código WTF" me refiero a código con una elevada medida de "WTF" como en la siguiente viñeta:

WCAG 2.0 (finalmente)

2008-12-13T17:40:00.004Z

En la página del WCAG WG tenemos finalmente WCAG 2.0, la nueva versión de las recomendaciones de accesibilidad. Para facilitarnos la vida tenemos una referencia rápida personalizable, una referencia comprensible (ya se podía hacer este tipo de cosas siempre que se hacen referencias ilegibles) y una guía de técnicas. ¡Incluso una lista de fallos comunes de accesibilidad!
Las recomendaciones se agrupan en cuatro principios. Una web debe ser correctamente...

percibible: la información y los componentes del interfaz deben presentarse de forma que sean percibibles por los usuarios: alternativas textuales, contraste adecuado, presentable con estructura más simple...
operable: accesible a través del teclado, facilitar la localización y la navegación...
comprensible: texto legible y comprensible, navegación consistente, tolerante a errores de usuario...
robusta: maximizar compatibilidad con agentes de usuario presentes y futuros...

Se mantienen los tres niveles A, AA y AAA que indica los "criterios de éxito" que cumple la página o la alternativa propuesta.

Se dice explícitamente que no pasa nada por usar tecnologías no accesibles, siempre que no afecten a los criterios de accesibilidad.

Sí, se puede usar Javascript. Usarlo no hace que tu página sea usable ni deje de serlo. Desaparece, por tanto, la mayor limitación técnica que existía con la WCAG 1.0.

Ni siquiera es necesario que la página esté correctamente formada. Adecuarse totalmente a especificaciones es una técnica suficiente para pasar directamente varios criterios, pero no necesaria.

De hecho, muchas de las técnicas estas líneas me recuerdan más a criterios de usabilidad que a accesibilidad, aunque siempre hemos sabido que al segundo se llega a través del primero. Por ejemplo, aquello de no hacer enlaces de "pulsa aquí".

Seguiremos teniendo que realizar un trabajo en formación y desarrollo para que una página sea accesible, pero será algo lógico, centrándonos de verdad en que la página sea accesible, no en pasar ciertos criterios porque lo ponga en una especificación.

Es un paso adelante. Me queda todavía mucho trabajo para analizarlo en profundidad, pero era muy importante que apareciese una nueva versión definitiva de esta especificación, el impacto, incluso legal, de la misma es muy importante.

Accesibilidad y aplicaciones web

2008-12-13T10:36:00.003Z

Hubo un tiempo en que la web era "sólo" información: texto, imágenes (poco más contenido multimedia, el ancho de banda era lamentable) e hiperenlaces. Como cualquiera se podía poner a hacer una página y los navegadores tragaban con todo el código era innecesariamente malo. Si a eso le sumamos la guerra de navegadores, en la que competían por ver cuál implementaba más etiquetas indeseables, no es difícil pensar la razón por la que los estándares web comenzaron a cobrar importancia.
Uno de los grupos de consolidación de estándares era el WCAG WG, encargado de algo tan loable como asegurarse de que aquella maraña de información cumplía unos requisitos mínimos para que la gente con discapacidad pueda disfrutar de ellos. En 1999 publican WCAG 1.0, la (única hasta hace poco) guía de referencia sobre qué es una página web accesible.
La web, que comenzó siendo puramente información, ha ido creciendo hasta tomar el papel de un simbionte en nuestra vida: la necesitamos para casi todo, y además ella se alimenta de nosotros, de nuestras aportaciones, en lo que se ha llamado Web 2.0. Se ha metido en nuestras vidas y en nuestros trabajos, en forma de aplicaciones web. Éstas no son sólo información, son también comportamiento. No son sólo una evolución de la web, sino que sustituyen a las aplicaciones de escritorio. Una aplicación web, técnicamente, es algo mucho más complejo que una página. Para que sea verdaderamente cómoda es necesario utilizar técnicas más avanzadas, que, entre otras cosas, implican scripts.
Eso choca con la WCAG 1.0, ya que en uno de sus puntos más restrictivos, dice que la página debe funcionar sin lenguajes de script. Eso lleva años sin ser asumible por una aplicación, especialmente desde que los usuarios exigen Ajax. El problema es que javascript ya NO es un problema real de accesibilidad. Los lectores de pantalla han mejorado notablemente, y no es necesario adherirse a una restricción tan exigente. El propio WCAG WG es consciente de ello y lleva años trabajando en la siguiente versión, que acaba de ser publicada. El 11 de diciembre de 2008 se ha publicado la primera versión pública no borrador de la guía WCAG 2.0. No sólo eso, sino que están trabajando en otra más, ARIA, que consigue que algo tan inaccesible (hasta ahora) como el framework GWT pueda serlo.

Esto, que personalmente es un hito alentador (¡voy a poder hacer aplicaciones web ajax accesibles de verdad y además certificadas!) legalmente en España sigue siendo un problema. Los políticos y abogados de este país no saben aquello del DRY, y disfrutan en su síndrome NIH. La norma UNE 139803:2004, sobre accesiblidad, en vez vez de decir algo como "la página web debe estar conforme a las especificaciones de accesibilidad del WCAG WG" es un cortapega de las normas presentes cuando fue redactada.

En mi opinión lo que debemos hacer es seguir WCAG 2.0 y/o ARIA, que son el presente y futuro de la accesibilidad web. Las demás consideraciones dejémoslas en manos de los abogados...

En breve, implicaciones de WCAG 2.0. ¡Stay tuned!

PD: mientras escribía esto ha sido cuando he visto que WCAG 2.0 es estable, no os imagináis el alegrón que me he llevado. Ahora, a empollarlo.

Los roles en el desarrollo de software

2008-12-08T17:07:00.004Z

A raíz de mi reciente incorporación al incipiente Centro Experimental del Conocimiento me ha venido a la mente el recurrente tema de los roles y las jerarquías en el desarrollo de software.

En developer.com han hecho una serie de artículos sobre los roles en el desarrollo de software. Una frase es especialmente reveladora sobre lo que creo que debe ser cualquier clasificación:

Developer (Dev) - The heart and soul of the process

Es una serie de artículos bastante interesantes, hablando no sólo de en qué consiste cierto papel sino en qué debes hacer si aspiras a ciertos puestos.

Al menos en mi alrededor a la gente que toma parte en el desarrollo de software se la clasifica en programadores, analistas, diseñadores y jefes de proyecto (obviando las divisiones transversales de becario, junior y senior). En paralelo a esta jerarquía existe la nube de comerciales.

Problemas

Esta división jerárquica tiene, en mi opinión, innumerables problemas. Primero enunciaré los problemas que veo, para acabar con mi propuesta.

El Principio de Peter

Las personas que realizan bien su trabajo son promocionadas a puestos de mayor responsabilidad una y otra vez, hasta que alcanzan su nivel de incompetencia.

A largo plazo se acaba en puestos para los que no se vale, símplemente porque el inferior se hacía bien. Sí, hay formas de mitigarlo, pero denota un problema de esencia en una organización jerárquica.

Ser programador no es fracasar

Hace poco me contaban de un ingeniero informático que se refería a otro prácticamente en términos de fracaso, símplemente porque está trabajando como programador. En la carrera muchos profesores nos educan que programar es una tarea de bajo nivel, sin interés, mecánica, indigna para ingenieros, apropiada para "la gente de módulos". Sólo estoy de acuerdo en una cosa: programar puede ser inadecuada para ingenieros, sí, pero porque han salido de la carrera sin saber programar ni hacer nada por intentarlo. Obviamente a esos les pondría delante de unos libros y un teclado, y les haría trabajar hasta que corrigiesen eso.
Hay autores que opinan que programar es automatizable (coincidencia o no, suelen ser vendedores de herramientas CASE). Yo me alineo con Robert L. Glass, que dice que el 80% del trabajo de programar es intelectual. Programar no es una tarea mecánica ni menor. Ser programador es un trabajo de responsabilidad, intelectual, que requiere dedicación, esfuerzo, autoexigencia y constante renovación. Tener buenos programadores es crítico para el desarrollo de un proyecto.
La jerarquía promueve la visión de que "lo que hay que conseguir" es salir de los puestos "inferiores" (programador) lo antes posible y "ascender" a puestos de mayor "responsabilidad" (y sueldo). Esto es simplista, erróneo e indeseable. Conozco programadores incapaces cuya único plan profesional es hacer tiempo en puestos de codificador hasta que el contador sea suficientemente grande como para que el mercado le promocione a analista. Yo no le quiero ni de programador, ni de analista.

Quiero desarrolladores, no programadores

La jerarquía hace que los programadores se conviertan símplemente en recursos que pican código, ¡tanto desde su punto de vista como desde el de sus "superiores"! La jerarquía les hace convertirse en personas sin responsabilidades, sin iniciativas propias, que no se implican en el trabajo de los demás, que no cuestionan los planteamientos...

Quiero trabajo en equipo, no delegación de la responsabilidad

El trabajo de un programador se limita a implementar la especificación de un diseñador. ¿Qué se consigue con esto?

Los programadores no se sienten con la responsabilidad de corregir el código de otros.
Los errores cometidos por los diseñadores no son corregidos, ya que nadie lo considera parte de su trabajo.
El trabajo de diseño lo hace una persona diferente al que realmente lo implementa (hecho #29 de "Facts and Fallacies of Software Engineering").
Se subcontrata el trabajo de programación, porque parece que no es importante, aunque al final lo que sucede es que las organizaciones dependen de subcontratas en sus herramientas clave, y el conocimiento adquirido se pierde al acabar el subcontrato.
Se acaba produciendo una separación entre los programadores, que se sienten minusvalorados, que no perciben formar parte de la organización, y el resto.

Si el modelo en cascada es erróneo, ¿para qué insistir en él?

Lo primero que te cuentan en Ingeniería del Software es el modelo en cascada, y lo segundo es que no vale como método de desarrollo. ¿Por qué insistimos en usarlo, directa o indirectamente? La jerarquía inicial no es más que el reflejo de esta metodología en el organigrama de la empresa.
En mi opinión, el proceso mental de desarrollo de software sí es en cascada, pero no se requiere de explicitación, de la misma forma que cuando se hace un modelo de datos se tienen en cuenta las formas normales pero no se explicitan.

¿Realmente respetas lo que implica la jerarquía en cascada?

Este tipo de jerarquías llevan implícito un orden numérico que suele obviarse. En un desglose tradicional del trabajo en cascada se asume que el nivel directamente inferior es numéricamente mayor: un jefe de proyecto, dos o tres analistas, cinco o seis diseñadores, diez o doce programadores... Esta organización puede tener un sentido cuando esto se respeta, y puede dar unas garantías que no dan otras, como que los analistas o diseñadores "firmen" partes del trabajo, asumiendo su corrección y adquiriendo su responsabilidad. Pero... ¿tu organización lo puede mantener? ¿Tiene sentido un proyecto en el que sus integrantes son un "analista" y dos "programadores"?

Reduce la versatilidad del equipo dificulta la gestión

Si alguien es programador no le pidas que haga de analista:

Le estarás pagando como programador pero estará asumiendo la responsabilidad de analista.
No tiene por qué asumir ese trabajo: no es analista.
Tendrá una visión de temporalidad de su trabajo.

Su uso refleja la inmadurez de la organización

Adoptarlo es una decisión que se adopta sin pensar. En mi opinión se adopta por los siguientes motivos:

Uso de metodologías en cascada (que no queremos, ¿no?).
Facilita la definición de la carrera profesional y salarial.
Situa a los comerciales en un punto muy elevado (cosa deseable, en mi experiencia, desde el punto de vista de los jefes).

Mi propuesta

No size fits all, así que un buen punto de partida es tirar a la basura la precondición de que la jerarquía es esa. Partiendo de eso...

Desarrolladores, no programadores, ni analistas, ni diseñadores

Un mismo miembro del equipo debe desarrollar su habilidad en todas las técnicas implicadas en el desarrollo. Además, adoptando el principio de desarrollo ágil de propiedad colectiva del código y extendiéndolo a cualquier otro producto del desarrollo, todos deben implicarse en el desarrollo, corrección y evolución del código, análisis y diseño.
Por otra parte, no me valen analistas que no saben programar. Deberíamos estar en una de esas condiciones que "nunca suceden", pero en la práctica sí hay analistas "puestos". Aunque el rol de analista funcional está ahí y es importante, sólo es un rol, no una responsabilidad ni una persona concreta. Lo mismo ocurre con el de arquitecto de soluciones (diseñador).
PD: aquí "análisis" y "diseño" no son las fases del modelo en cascada, sino las técnicas que se llevan a cabo para la resolución de ciertos problemas funcionales o técnicos ;)

Separa las condiciones contractuales de tu rol en los proyectos y en la organización

Si alguien es un buen desarrollador y está a gusto en ello, debe poder desarrollar toda su vida profesional como tal. Haz que un desarrollador pueda comenzar en tu empresa como becario o junior pero que pueda desempeñar ese mismo trabajo durante años, y que su contrato mejore en consecuencia. ¿Por qué un gran programador que lleva muchos años en la empresa no puede cobrar más que cualquier comercial? Permite un cambio de rol si él quiere y realmente vale, pero no lo impongas como necesario para mejoras contractuales. Esto conseguirá que los desarrolladores estén realmente motivados: verán su trabajo recompensado, tendrán responsabilidades...

Implica a las personas, no a los roles, en las decisiones clave de la organización

¡Haz que él también lo sepa! Tenle en cuenta a la hora de tomar decisiones técnicas. Que sepa que su papel en la organización no es sólo codificar.

¿Es esto válido en cualquier caso?

No, no size fits all. En el fondo estas ideas están fuertemente influenciadas por mi trabajo en aplicaciones web y de gestión, y en mi convencimiento de que una metodología de trabajo ágil es lo mejor en la mayor parte de los desarrollos. Siempre digo lo mismo: algo así no vale en todos los casos. Por ejemplo, si piensas desarrollar el software para poner un satélite en órbita, necesitarás un proceso muy estricto en el que las especificaciones pasen por muchas manos para asegurar su validez y determinar las responsabilidades.
Pero no ponemos satélites en órbita a diario. Creo que por defecto la organización debería reflejar las tendencias de los últimos años, y relegar las tradicionales a campos en los que son más adecuadas.

Reseña: Facts and Fallacies of Software Engineering

2008-12-02T16:23:00.002Z

Facts and Fallacies of Software Engineering (FFSE, para abreviar) es un libro que recopila "55 hechos y 5 + 5 falacias" (al autor le gustaba la reiteración de la 'f') del desarrollo del software. Los hechos son un resumen de lo que considera más importante saber a la hora de gestionar y desarrollar proyectos software, y las falacias, los engaños o equivocaciones más frecuentemente extendidos como ciertas.

El autor es Robert L. Glass, uno de los pioneros en el desarrollo de software: lleva más de 54 años metido en esto, así que algo debe saber. Publica un newsletter bimensual de pago, The Software Practitioner. Declara que, tras haber trabajado tanto desarrollando como gestionando, "le gusta más hacer que dirigir hacer a otros". Un tipo así no me podía caer mal.

La estructura de cada hecho o falacia siempre es la misma: expone el contenido, la controversia (si la hay), y concluye con las fuentes y referencias citadas.

Ejemplos de hechos:

El factor más importante es la calidad de los programadores.
Los mejores programadores son hasta 28 veces mejores que los peores.
Una de las dos causas más probables de fracaso de proyectos son los requisitos inestables.
Eliminar los errores es la fase que más tiempo consume del ciclo de vida.
La estimación se hace en el momento equivocado y la hace la gente equivocada.

Ejemplos de falacias:

No puedes gestionar lo que no puedes medir.
Herramientas y técnicas: una vale para todos los casos.

El balance del libro no es positivo, pero más por culpa de mis expectativas que porque el libro falle. Me ha decepcionado, probablemente me equivoqué al encargarlo, me tenía que haber informado más. Mi primer fallo es no haber hecho cuenta de lo que implica que sean sólo 200 páginas. No me gustan los libros innecesariamente grandes, pero considerando que se ocupa de 65 temas, eso deja poco más de tres páginas para cada uno. Si a eso añadimos que de esas tres páginas un trozo no despreciable se va en citar fuentes, podéis imaginar que no trata en profundidad casi nada. Cada hecho se resume a mostrar su opinión, citando ejemplos o fuentes interesantes, y comentar muy por encima la discusión al respecto.
A esto le uno que estoy de acuerdo con prácticamente todo, y con todo lo importante, así que en mí genera poco debate, que es siempre una de las cosas interesantes de leer opiniones ("¿No pensamos igual? ¿Estoy equivocado, o es él?"). Para que me den la razón en todo prefiero no leer o no discutir, lo interesante es cuando las opiniones no son iguales.

Lo mejor

Es una buena recopilación del "estado del arte" de la ingeniería del software, para ver de qué pie cojeamos.
Es gratificante ver que no soy el único que le preguntó a su profesor (bueno, él a sus alumnos) que por qué la estimación se sitúa antes de la recogida de requisitos sin obtener respuesta :).
Las fuentes son una buena biblioteca que todos los ingenieros del software deberíamos leer.
~~Tener algo físico que lanzarle a tu jefe a la cabeza~~. Tener una opinión más contrastada que la propia que poder utilizar como argumento con jefes y gestores que desprecian la programación y otras tareas triviales de esto de desarrollar aplicaciones.

Lo peor

No entra en profundidad.
No se aportan soluciones a los problemas.
Las cifras concretas aportadas, sin que las considere importantes de todas formas, me siguen pareciendo vagas y poco contrastables. Valen como idea general, pero no como cálculo aproximado (aunque puede que nunca lo vayan a ser, así que lo mejor creo que sería no intentar aportar cifras).

Manifestación Informática 19N

2008-11-19T19:26:00.002Z

Manifestación Informática 19N
Cargado originalmente por alberto.ipollo

Hoy era el día.

Mi opinión sobre la huelga era que había que hacerla, todos. Sobre todo, para curarnos en salud de lo que pueda pasar. Por mí, le quitaba las atribuciones a todo el mundo. Lo que no quiero es que al final le acaben dando las mías a otro. Y todo apunta a que el ninguneo que sufre nuestra carrera puede llevar a eso.

El balance ha sido mediocre. Me he encontrado con mucha gente que no veía desde la facultad, y eso es bueno porque quiere decir que desde las empresas nos hemos movilizado bastante. Pero, por otro lado, me han faltado estudiantes. Al no ser una huelga oficial ha habido gente que trabaja que no la ha podido secundar, así que mi esperanza era que se movilizase el colectivo de estudiantes.

De todas formas, es bueno ver que nos empezamos a mover, y que esto se ha repetido en toda España (basta con buscar en Flickr).

Es un pequeño paso para nosotros, a ver si es el comienzo de un buen camino.

Pondría una foto de las mías, pero ésta de Alberto es mucho mejor.

Problemas a la hora de la huelga

2008-11-12T07:33:00.003Z

[Actualización 081112]: la respuesta por parte de un representante de UGT ha sido que los sindicatos no apoyan (ni apoyarán) la huelga por no existir un sindicato sectorial que agrupe a los informáticos. Por tanto, la vía que nos queda es formar asambleas de trabajadores afectados, votar, y realizar a la empresa la solicitud formal de la huelga. En la página de la huelga están los modelos para estos trámites. NO se necesita al comité de empresa y NO se necesita un 33% de la plantilla, los trabajadores tienen derecho a huelga a título individual. Los que estamos en empresas públicas llegamos tarde, deberíamos haberlo pedido con 10 días naturales (aún así lo estamos solicitando, para que al menos quede constancia). Los que estéis en empresas privadas estáis a tiempo todavía.

En mi empresa está circulando esta ayuda:

Desde el ITA estamos intentando apoyar la huelga, pero creo que la sensación general tanto aquí como en otras empresas es que no sabemos cómo hacerlo, resumo en este correo los problemas que estamos teniendo a la hora de irnos a la huelga y las soluciones que vemos.

El principal problema es que la huelga no está convocada por ningún sindicato, con lo cuál o presionamos a los sindicatos para que la convoquen o hay que convocarla en cada empresa por separado. Movilizando a los sindicatos mayoritarios la gente se podría adscribir a la huelga sin tener que estar montando tinglados en cada empresa por separado.

Las vías que tenemos son:

Movilización de los sindicatos
Movilizando a los sindicatos mayoritarios la gente se podría adscribir a la huelga sin tener que estar montando tinglados en cada empresa por separado.
Las vías que tenemos son:
- Presionar a los comités de empresa y secciones sindicales para que contacten con la delegación provincial de Valladolid (Unión provincial UGT Valladolid por ejemplo) para que convoquen la huelga al menos en Valladolid, con esto todos nos podríamos ir a la huelga sin tener que solicitarla.
- Otro frente son las sindicatos sectoriales, informáticos no tenemos en general, pero sí existe en el caso de UGT una Federación de servicios públicos en la que entraría la gente que trabaja en la administración (FSP), este sería otra vía de presión, que la gente que trabaja en la administración hable con sus secciones sindicales o comités y hablen con la delegación para que se convoque la huelga.
- Los colegios profesionales de informáticos deberían estar haciendo lo mismo, presionar, pero incluso a nivel nacional para que sea UGT-nacional, CCOO, etc,… la que convoque la huelga.

Por supuesto hablo de UGT pero porque es lo que me han comentado, lo mismo CCOO, CGT

Convocatoria de huelga en empresa
Si con lo anterior no conseguimos nada, la alternativa es convocarla en cada empresa, la convocatoria la puede hacer el comité de empresa o una asamblea de los trabajadores afectados con mayoría absoluta. Para convocar la huelga:
- Crear asamblea eligiendo a un presidente y secretario
- Celebrar votación secreta
- Si se aprueba por mayoría simple nombrar un comité de huelga.
- Reflejar en un acta el motivo de la asamblea, el resultado de la votación (resultado no hace falta los votos particulares) y el comité de huelga y que lo firmen presidente y secretario.
- Notificar a la empresa de la huelga (modelo de preaviso)
- Notificar a la delegación provincial de trabajo y a la delegación de gobierno. (modelos de comunicación de HUELGA)
Esto es para convocar la huelga, después la gente se puede adscribir a la huelga el mismo día sin aviso.

En resumen: que cada uno que reciba este correo haga dos tareas muy simples:
1.- Reenviarlo a la gente interesada. (por favor es independiente de que estés o no de acuerdo con hacer huelga).
2.- Con los que tenga al lado, que se junte y sin esperar más busque el teléfono de alguien de su comité de empresa y le pida que contacte con la delegación provincial para que convoquen la huelga. Si desde vuestro comité no son permeables al tema, intentad directamente contactar con la delegación provincial de UGT /CCOO/CGT o presentad un escrito al comité solicitándolo.

Iba a poner un tercer punto de contactar con colegio profesional (de Castilla y León) pero en Valladolid esto no está sirviendo para nada, sinceramente yo plantearía presentar un escrito al colegio para que devuelvan las cuotas que están cobrando porque no sabemos exactamente qué hacen con el dinero si en casos como estos no se mueven.

PD: la opinión aquí reflejada sobre el colegio de castilla y león se debe a dos cosas:
Consideramos que a falta de un sindicato sectorial, el Colegio es el que debería organizar este tipo de movimientos, encabezando manifestaciones y ayudando en trámites legales. Creemos que no sólo no han hecho nada (más que decir que la apoyan) sino que la respuesta dada a una consulta de un compañero es... pobre, por decirlo suavemente. En mi opinión, cuando escribes a alguien en un Colegio pidiendo ayuda para una huelga es algo serio, y prefiero que me digan que no me pueden ayudar a que contesten con chascarrillos. A título personal, perfecto. Pero cuando escribes a una asociación de lo que sea, no preguntas a la persona, sino al colectivo. Por ejemplo, pese a todo lo que se está moviendo estos días, en la página principal se ve que símplemente se hacen eco de lo resuelto en el Consejo de Colegios, sin decir ni proponer ninguna otra cosa (bueno, una tira cómica)

Mi opinión sobre el estado de la informática

2008-11-08T09:36:00.009Z

[Actualización 0811081720: "Sobre la huelga"]
[Actualización 0811081742: enlace al blog de Enrique Barreiro]

Antes de nada, y como ya dije en otro lugar, esto que pongo aquí es, como siempre que hablo, IMHO :)

Estos días está habiendo un flame tremendo a cuenta de la regulación de informática, de telecomunicaciones, de las enseñanzas europeas, y de la huelga informática. No enlazo los temas anteriores porque si has llegado hasta aquí seguramente tengas en tu bandeja de entrada referencias por triplicado a ellos.

He puesto mi (micro) opinión en twitter y también he opinado en el blog de informática de un amiguete, pero he creído conveniente resumirlo aquí también. Me centraré en resumir mi opinión, porque rebatir argumentos ya lo he hecho en el otro blog (y es bastante aburrido).

Dos enlaces: Bolonia for dummies me ha sido de gran ayuda. Me parece un gran post: útil, con datos, perfectamente escrito, y objetivo. Otro fundamental es la explicación de Enrique Barreiro.

Sobre la regulación profesional
No me gusta la regulación, en casi nada de la vida. Creo en la autoregulación del mercado y de la sociedad en general. Creo que cuanto menos se entrometan los gobiernos en nuestra vida, mejor. Y creo en el reconocimiento personal, no colectivo.
Por esto mismo, no me gusta la regulación profesional. En mi opinión un título no demuestra nada. Yo quiero ser bueno en mi trabajo, y que eso me lleve a tener un buen puesto, un buen sueldo, y una buena vida en general. Mi vía para eso fue sacarme el título de Ingeniería Informática, pero estoy convencido de que no es la única. Hay gente no titulados, de módulos, titulados técnicos y titulados superiores de otras carreras (sí, también telecos) que son profesionales infinitamente mejores que yo: saben muchísimo más, son más productivos y más trabajadores. Y los hay peores: veo titulados que no llegan ni al nivel de un "usuario avanzado". Por tanto, el título no demuestra nada, y, por tanto, nadie debe estar obligado a contratar o no a alguien porque tenga un título. No nos engañemos: la regulación de atribuciones profesionales no da derechos, sino que impone obligaciones.
Toda regla tiene su excepción: no, no creo que nuestra carrera sea igual que la de un médico. Yo, cuando escribo código, no tengo constantemente la vida de nadie en mis manos. Es cierto que sí puedo diseñar sistemas críticos, en cuyo caso sí deberían ser exigibles todas las garantías posibles (y el título podría ser una de ellas), pero de ahí a compararme con un médico, ni de lejos. No soy médico porque ni me gusta ni creo valer para ello.

Sobre la intromisión profesional
Este es uno de los grandes llantos de nuestro sector. Distinguiré entre dos casos, la intromisión 'razonable' y la intromisión 'lamentable'.
Sobre la intromisión lamentable
La intromisión 'lamentable' es esa que se da en ciertas empresas carniceras en la que los jefes gestionan los programadores por peso, y les da igual que sea Ingeniero Superior en Informática con 10 años de experiencia que un Licenciado en Historia con un curso de Java (curiosamente a esos jefes "no les gusta programar", lo cual realmente significa que no tienen ni idea ni de programar ni de informática). Esas empresas merecen el máximo de mis desprecios, y me dan exactamente igual que se vayan a pique en el mayor de los estrépitos. Si eres un buen informático y estás haciendo un proyecto en una empresa en la que cogen a alguien que no tiene ni idea y le pagan tanto o más que a tí, ¿qué haces allí? Cambia de empresa. Creo que los informáticos, aunque cobremos más, salimos mucho más baratos. Y eso se tiene que demostrar a diario, con hechos, lo cual debería llevar a que esta intromisión lamentable desapareciese por selección natural: las empresas que pretendan sacar así los proyectos desaparecerán, y las que hagan lo contrario, prosperarán. Mirad, como siempre, a Google: contrata a los mejores y les da un buen salario y una buena vida. De ahí no puede salir nada malo.

PD: perdón a los Licenciados en Historia por ponerles como ejemplo, espero que comprendáis el argumento :). Y sí, seguro que hay alguno que es mejor informático que muchos, como digo arriba :).

Sobre la intromisión razonable
El hecho innegable es que hay mucha demanda de informáticos. Sí, estamos mal, pero aún así, laboralmente puede que seamos de las carreras con una mejor situación, pese a la crisis. No me cambio por algún amigo Ingeniero Químico, por muchas atribuciones profesionales que tengan.
La demanda es tal que la oferta no es suficiente (¿conocéis informáticos en paro?) y se necesitan más informáticos de los que lo son profesionalmente (módulos, técnicos y superiores). Aceptando este argumento, creo que es razonable que, salvo que prefiramos que no se hagan los proyectos, entren otros a hacer nuestro trabajo.
En esta intromisión, los que están mejor situados, por perfil, son los telecos. Apenas dan nada de informática en la carrera, pero sí hacen cosas, y su preparación les debe predisponer a aprender con cierta facilidad. Eso es así. ¿Dónde está el problema? El hecho es que se necesitan informáticos, ¿qué problema hay en que sean telecos? Si la persona es apta, inteligente, capaz, ¿por qué no? Otra cosa es que sea un perfecto inepto y encima le asciendan, claro. Pero ese es otro problema.

Sobre los telecos
Hace años me dijeron que teleco es una carrera diseñada a imagen y semejanza del perfil que Telefónica necesitaba hace tiempo, lo cual explica muchas cosas. Creo que el 90% los conocimientos que les imparten en la práctica ya no valen para nada. El perfil que se crea no tiene salidas profesionales ya, Telefónica dejó de demandarlo hace tiempo. Los amigos telecos que tengo están casi todos colocados por Madrid, en consultoras, de auditores o similar. Les cogieron por ser personas válidas, no por sus conocimientos. Parece que esto es suficiente para que muchos informáticos quieran condenarles al ostracismo, temerosos de que nos quiten el trabajo. No me malinterpretéis: creo que el teleco prototípico no puede ser comparado informáticamente con el informático prototípico. Pero eso es eso, estereotipos.
Pero también he visto lo contrario: telecos que no sólo son inteligentes y trabajadores, sino también buenos informáticos.
Todo esto me lleva a lo siguiente: Teleco es una carrera que necesita una reorientación, o desaparecer. Como hacerla desaparecer no es viable, veo normal que lo reorienten, mediante estas fichas académicas de Bolonia, hacia informática. "La sociedad necesita informáticos, formemos más". A mí, mientras no les den atribuciones profesionales que nos excluyan a los informáticos, me parece bien.

Sobre el reconocimiento profesional
El otro llanto habitual es lo mal reconocida que está nuestra carrera. Es cierto. La sociedad en general piensa que se informático es usar el Word, instalar Windows, y estar encerrado en el dormitorio chateando. Bueno. ¿Y qué? ¿Los jefes que nos pagan piensan eso? No. ¿Que el tuyo sí? Vete de esa empresa.
Demos la vuelta a esto, y hagamos algo de autocrítica:

A veces nos creemos semidioses. Nuestro título nos convierte en una esponja ávida de conocimientos, un Neo capaz de aprender en segundos cualquier cosa, nos da bula para descalificar a todos, nos concede el don de la infabilidad.
Ni nosotros valoramos la programación. Hace años escuchaba a un profesor hablar con desprecio de la salida profesional de programar, y ayer mismo me hablaban de un informático que se refería a los programadores como fracasados.
Seamos más exigentes con nosotros mismos. Nos pasamos el día despotricando sobre el trabajo de los demás ("puto Windows", "qué lento va el Eclipse", "qué mierda es J2EE"...) y no nos damos cuenta de lo mal que hacemos a veces nuestro trabajo ("bueno, lo cortapego y ya está", "así funciona, sé que está mal pero no lo toques"...).
Menos quejarnos, y más movimiento: ¿nuestro jefe teleco es un inepto que no nos deja trabajar correctamente? Hagamos propuestas, ofrezcamos alternativas, demostremos que se puede hacer mejor. O cambiemos de empresa. ¡O hagamos una!

Sobre la huelga
Supongo que después de lo expuesto aquí se esperará que esté en contra de ir a la huelga. Si dependiese exclusivamente de mí, la verdad es que no iría. Sin embargo, si el sector decide movilizarse, con los colegios encabezando la manifestación, creo que mi obligación es secundarla. Creo que el problema es algo sobre lo que hay que informarse y discutir. Mi conclusión, tras haberlo hecho, es que no hay razón para la alarma social, aunque sí hay motivos para estar descontento. ¿Justifica esto una huelga? No lo sé. Pero si la mayor parte del sector piensa que sí, y eso incluye a los colegios, creo que todos debemos apoyarlo. Los trapos sucios se lavan en casa, pero en la calle debemos ser uno. Individualmente puedo pensar que no hay motivo para una huelga, pero esa es una discusión que debemos mantener los informáticos. Sin embargo, si el colectivo piensa lo contrario que yo, creo que lo correcto es unirme. Si no hiciese esto sería como si me junto con un grupo de amigos para ir de vacaciones pero sólo voy si van donde yo quiero.

Conclusión
Sí, la situación actual es mejorable. Pero ni los telecos son el demonio, ni nosotros somos dioses, ni un título demuestra nada. Y la informática no es Medicina, yo puedo depurar mis fallos, un médico no puede resucitar. Si yo programo un brazo quirúrgico, que me exijan garantías, pero para hacer una aplicación web, que me dejen tranquilo. Bolonia no nos va a borrar el cerebro, ni va a hacer que nos despidan. A mí, con que no me quiten, con que no me excluyan, con que no pongan a otros porque sí en mi lugar, me vale. Si un teleco es mejor informático que yo, que le contraten a él. Sólo pido que nadie deba contratar a otro en vez que a mí porque lo diga una ley, y eso, a día de hoy, no va a ocurrir. Y si los informáticos somos mejores que otros, demostrémoslo. Manejemos las herramientas como nuestras propias manos. Conozcamos la industria y el estado de la tecnología. Abracemos los cambios y las novedades. Tengamos iniciativa y seamos exigentes con nosotros mismos.

IMHO, claro :)

PD: este post es, por su propia naturaleza, de los que no aportan nada: sólo es mi opinión. Lo único interesante que puede salir de él es una discusión (¡entendida como debate!), así que todo comentario será especialmente bienvenido.

Eclipse: el núcleo del entorno de desarrollo

2008-11-01T20:50:00.002Z

[Actualización 081101: Maven2, JBoss Tools con Seam]
[Actualización 081102: TestNG]

Un programador debe programar. Se programa con el . Todo lo que le suponga a la persona salirse de él, va a ser trabajo adicional que no es bienvenido.
Sin embargo, en el entorno de desarrollo tenemos repositorio de código, gestor de tareas, servidores, bases de datos, sistemas de integración contínua... Todas esas herramientas tienen su utilidad, pero interesa controlar todo desde un único punto.
Además, probablemente tengamos a un señor con corbata empeñado en saber en qué emplean las horas los programadores, cómo van los proyectos... Tenemos que maximizar la información minimizando el trabajo de soporte.
Nuestro objetivo aquí es integrar el Eclipse con el resto de herramientas lo máximo posible. En este breve artículo hablaremos también de Mylyn, ese "interfaz orientado a tareas" que integra Ganymede.

Nos centraremos en la forma de integrar Eclipse con el resto de elementos del entorno, dejando las virtudes y defectos de cada uno en los enlaces sugeridos.

Subversion
Una de las razones para usar Subversion sobre CVS es que Ganymede integra soporte nativo para el mismo. Bueno, casi. Por un problema de licencias tendremos que instalar el plugin de Subversive y un conector SVN.
En los enlaces tenemos los update center que configurar en Eclipse para instalar todo. Partiendo del Eclipse J2EE no lo conseguí. Insisto en mi recomendación de comenzar con el Eclipse básico.
El trabajo diario de sincronización esencialmente es igual que con el CVS, así que no voy a profundizar más en esto.
// TODO: ¿cambios?

Trac
Para poder conectar el Trac como repositorio de tareas con Mylyn/Eclipse hay que hacer dos pasos adicionales.
Por un lado, tenemos que instalar el conector de Trac, que no viene en la distribución por defecto de Mylyn. En la página de descarga de Mylyn tenemos el update center de los extras.
Por otro, tenemos que instalar el plugin que permite acceder a Trac mediante xml rpc.
Hecho esto podremos configurar el repositorio de tareas del proyecto (propiedades del proyecto --> Repositorio de tareas --> Añadir nuevo repositorio). En la vista "Task list" (no confundir con la tradicional "Tasks" de TODOs y FIXMEs) tendremos los tickets. Si no te aparecen todos (como a mí), botón derecho sobre la vista --> new --> query, y sin filtrar te aparecerá.
Si quieres saber qué es Mylyn, echa un ojo al webminar. Realmente creo que es muy interesante, y que puede cambiar (¡y facilitar!) la forma de trabajar.
Desde el punto de vista de la integración con Trac, se puede tanto crear nuevas tareas/tickets como editar los existentes. Además, marcar una tarea como activa registra el tiempo empleado en ella. A aprenderse los atajos de Mylyn ;).
Hay cosas que todavía no están integradas como ambos, como el seguimiento de tareas, pero están en ello.

JBoss Server
JBoss, aparte de tener su propia versión de Eclipse, el JBoss Developer Studio (de pago, que yo creía que iban a redenominar Red Hat Developer Studio), libera un conjunto de plugins bajo la denominación JBoss Tools que puedes descargar.
Desde la vista "Servers" se pueden crear nuevos servidores. Hay conectores específicos para cada versión, que se autoconfiguran con indicar el directorio donde has descomprimido la distribución del servidor.

Seam
Seam es la niña bonita de JBoss en lo que a desarrollo Java empresarial en estos momentos, y JBoss Tools tiene soporte para ello. Para activarlo, en las propiedades de Eclipse, buscamos Seam y configuramos la ruta en la que nos hemos descargado el framework.

Google App Engine (PyDev)
La integración de Eclipse hacia el Google App Engine la conseguiremos a través de PyDev.
Una vez configurado el PyDev (consultar documentación), añadimos los módulos de Google App Engine para que funcione el autocompletar, entre otras cosas. Hay que meter en los módulos el directorio en el que hemos descomprimido el GAE, y los tres que hay dentro de lib (más información sobre configurar GAE en PyDev en otro blog).

También interesa ejecutar el servidor desde el entorno, especialmente para ver en la consola los mensajes. Creamos una nueva configuración de lanzamiento (Run --> Run Configurations... --> New --> Phython Run). Como módulo principal configuraremos la ruta al lanzamiento del servidor, "dev_appserver.py". En el PYTHONPATH estarán las de python y una de pydev (al menos con mi versión) Como argumentos, estos (el puerto es un ejemplo):
${project_loc}
--port=9999

MySQL
Descargamos el mysql java connector.
En la vista "Data Source Explorer" podemos definir una conexión a una base de datos. Con el botón "New Connection Profile" elegiremos "Generic JDBC", un nombre, y pondremos la siguiente configuración (ejemplo de acceso a mi base de datos de Amarok):
URL: jdbc:mysql://localhost:3306/amarok
Driver class: com.mysql.jdbc.Driver
Usuario y nombre de la base de datos.
Jar descargado del conector.

Hudson
Se está desarrollando un plugin para conectar Eclipse con Hudson, actualmente en su versión 1.0.4. Introduce una vista en la que se listan los builds, y un icono con el estado de los mismos.

Maven2
Hay un plugin de Maven2 para Eclipse. Al instalarlo me dí cuenta de que no estaba ejecutando Eclipse sobre el JDK de Sun, sino sobre otro JRE (requisito de Maven2). Para solucionarlo, sudo aptitude install sun-java6-jdk, y sudo update-alternatives --set java /usr/lib/jvm/java-6-sun/jre/bin/java.

TestNG
Hay un plugin de TestNG para Eclipse. Tras instalarlo basta con botón derecho --> Run As --> TestNG Suite sobre una prueba para ejecutarla.

Organizando un entorno de desarrollo libre

2008-11-01T20:01:00.002Z

[Actualización 081101: Maven2]
[Actualización 081102: TestNG]

Como el movimiento se demuestra andando, he invertido unas cuantas horas en preparar un entorno de desarrollo. En los próximos meses tengo en mente hacer desarrollos en Google App Engine (Python) y también con Seam (J2EE), así que es un buen momento para para probar herramientas diversas. El objetivo es que, asumiendo los costes de instalación y de aprendizaje, el trabajo diario sea sencillo y completo, para lo cual es fundamental la integración de las herramientas.
Consta de los siguientes elementos principales:

Vayamos por partes, indicando brevemente la motivación y las referencias utilizadas.

Kubuntu
Usar GNU/Linux para desarrollo basado en herramientas libres es comodísimo y potente. La instalación de las herramientas viene soportada por APT, y mediante ficheros de configuración y módulos adicionales se puede hacer casi cualquier cosa. Lo he intentado en Windows y no me parece tan sencillo.
(K)Ubuntu porque es amigable con el usuario a la vez que tiene lo bueno de Debian (¡APT!), y no requiere compilar todo como Gentoo. Además, hay muchísima documentación actualizada. Y Kubuntu en vez de Ubuntu porque soy de KDE.

Instalarlo habría sido trivial si no me hubiese empeñado en usar el FakeRAID de la placa (ya que lo pagas...). Seguí las fantásticas instrucciones para instalar Linux Ubuntu 8.04 sobre un FakeRAID que ha compartido Vicente Navarro y no hubo mayor problema.

Repositorio Subversion
En las últimas semanas he sufrido un número ingente de conflictos entre ramas de un proyecto en el que trabajo con CVS, y quiero saber si Subversion ha mejorado algo esto. Aparte de CVS y SVN hay otros muchos SCMs, pero no he querido complicarme más para que el resto de herramientas (Eclipse, Hudson, Trac...) se puedan conectar a él sin problemas.
Apt-get, un poco de configuración en un par de ficheros, y tienes tu servidor SVN montado. Utilicé una guía de SVN en Ubuntu en castellano, y otra en inglés para rellenar los huecos de autenticación de la primera.

Trac
Buscando gestores de incidencias libres los más habituales parecen ser Trac y Bugzilla. Éste segundo tiene fama de monstruoso y complejo de administrar, lo cual no era opción en mi entorno. Trac, por el contrario, es sencillo, lo voy a poder conectar con Eclipse, se conecta al SVN, integra un wiki, es extensible mediante plugins...
Para instalarlo lo obtenemos con apt-get y seguimos la guía de instalación.

JBoss Server 4.2
El desarrollo Java pretendo hacerlo con Seam, que es de JBoss, así que me parece la elección más cómoda. Ya he sufrido el SJSAS/Glassfish, que no tiene por qué ser un mal servidor, pero no lo tienen en cuenta al documentar las librerías, y quiero probar otras cosas. JBoss Server es un servidor completo y con soporte profesional en caso de necesitarlo. Contiene a Tomcat como servidor web. Hice una prueba rápida con Seam en la versión 5 pero el despliegue fallaba, así que he preferido mantenerme en la 4.2, más contrastada.
Tampoco lo he encontrado en repositorios APT, así que a bajarlo a mano. Como pretendo usarlo de desarrollo, lanzado desde Eclipse, ni me molesto en crear el servicio.

Google App Engine
Acostumbrado a J2EE, probar Google App Engine me parece muy interesante para dejar de elegir Java por defecto. Desde que pasé de PHP a Struts no había usado lenguajes de script para desarrollo web.
Todo lo que necesitas saber para comenzar está en el tutorial básico.

MySQL
Profesionalmente siempre había usado Oracle. Al elegir una base de datos libre la elección sencilla es MySQL.
Tanto el cliente como el servidor están en APT, así que la instalación es sencilla.

Eclipse
No hay mucho que decir. No dudo que haya otros también muy buenos, pero Eclipse es el IDE de referencia. Como con SVN o Trac además, no sólo lo elijo por él en sí mismo, sino por su extensibilidad y conectividad.

La última versión es Ganymede. No está en ningún repositorio APT todavía, así que hay que instalarlo tradicionalmente. Inicialmente bajé el paquete J2EE, pero después aparecían problemas de compatibilidad de paquetes de plugins, así que mejor bajar el "clásico" y luego añadirle lo que sea.

Mylyn
Mylyn es una parte de Eclipse que favorece el desarrollo orientado a tareas. Integra en una vista las tareas asignadas, lleva conteo del tiempo empleado, asocia a cada tarea un contexto (para abrir los ficheros interesantes en cada momento) y un largo etcétera. Es algo que puede cambiar la forma de trabajar (¡para bien!). Igual que el Lightroom favorece el flujo de trabajo de un fotógrafo, Mylyn lo hace del programador.
Viene de serie con Ganymede, así que no hay más que hablar.

PyDev
Llevo años con Eclipse y probablemente me quedan unos cuantos más, así que quiero seguir usando ese entorno para programar también en Python. PyDev es el plugin de referencia, y para quien quiera pagar por más, tienen una extensión al mismo.

Hudson
Tras documentarme y ver que no hay uno realmente dominante en el mercado, y que ninguno "lo tiene todo", utilicé esta matriz comparativa de sistemas de integración contínua para elegir el más adecuado. Los más comentados, Cruise Control y Continuum, los descarté por no soportar Trac. Hasta donde sé el tercero en discordia entre los libres es Hudson, que sí tenía todo lo que necesitaba (y también extensible mediante plugins), así que es el elegido. En el libro Java Power Tools (una interesante referencia de herramientas actuales) revisan esos tres junto a LuntBuild.
La "instalación" de Hudson consiste en bajarse el war y ejecutarlo con java -jar hudson.war --httpPort=7777.

Maven
Maven es una herramienta para gestionar varios aspectos de un proyecto: dependencias, compilación, documentación... Se podría ver como un recubriento de Ant orientado a proyectos.
Aparte de las ventajas directas de usarlo, se produce un efecto colateral: el despliegue en un sistema de integración contínua de un proyecto configurado para Maven es trivial (si el sistema de IC lo soporta, claro).
En Kubuntu, con un sudo aptitude install maven2 ya tenemos la herramienta instalada.

TestNG
TestNG es un framework de pruebas que pretende cubrir limitaciones de JUnit a la vez que hacerlo más sencillo. Lo que es más imperioso en nuestro caso, es el framework de pruebas hacia el que está orientado Seam, por lo que será el que usemos.

En próximas entregas, la integración entre ellos.

Kubuntu 8.10: Todavía no, pero casi...

2008-11-01T10:18:00.004Z

A mí me encanta GNU/Linux. Me resulta una plataforma completa, personalizable, potente y estable, tanto para trabajo, servidor, o casa. Pero claro, yo soy informático y mi perfil no es el mismo que el de mis padres o mis amigos.
Periódicamente, normalemente coincidiendo con nuevas versiones de las distribuciones más populares, vuelvo a hacerme la misma pregunta: "¿Está GNU/Linux listo para el escritorio?"
En junio instalé Kubuntu y desde entonces pensé que "casi" estaba. Lo único complicado que he tenido que hacer para que funcionase todo fue seguir unas instrucciones para instalar el FakeRAID en Ubuntu, pero bueno, un usuario medio tampoco se para en RAIDs.
Hace un par de días actualicé a Intrepid Ibex, la versión 8.10. En estos momentos todo va sobre ruedas, pero desde que comencé la actualización me topé con un par de problemas que no habrían sido admisibles para un usuario medio:

Durante la instalación se pide intervención del usuario por conflictos en ficheros de actualización. Se muestra un diálogo con la salida de diff, y se espera que el usuario sea capaz de decidir correctamente. Vale, my.cnf y apache2.conf no son ficheros que habría tenido un usuario medio, pero sí la configuración de alsa-base.
Al reiniciar, no funcionaban las X. Tras buscar ví que estaba cargando un kernel incorrecto, para el cual los drivers no estaban actualizados. No sé si durante la instalación hice algo mal para que el menu.lst de grub no se hubiese actualizado, pero tuve que editarlo a mano para meter la entrada del nuevo kernel.

Yo, personalmente, estoy muy contento con Kubuntu y estos problemas, para mí, me parecen admisibles, pero pienso en la cara de mis padres o amigos si tras actualizar les saliese un pantallazo negro del terminal, y sé que en ese momento GNU/Linux habría muerto para ellos.
En GNU/Linux ya se ha llegado al punto de que cuando todo va bien, un usuario normal no tiene ningún problema (como la madre de converso72), que no es poco. Navegar por internet, usar la red, abrir ficheros de Office... Todo funciona.
En mi opinión, ya está cubierta el 90% de la funcionalidad. El problema seguramente sea que el 10% restante es bastante más de el 10% de trabajo, y mucho menos vistoso:

Hacer el entorno más tolerante a fallos y errores humanos. Las X son básicas. Por ejemplo, símplemente que en caso de error tome el fichero failsafe sería un buen avance.
Automatización de las configuraciones. KDE4 tiene procesos para actualizar los ficheros de usuario de KDE3. Esa es la línea. Todos los programas que utilicen ficheros de configuración deberían hacerlo automáticamente.

Un usuario nunca tendría que necesitar tocar un fichero de configuración. El día que eso ocurra, GNU/Linux estará listo.

Scrum - Introducción a las metodologías ágiles

2008-10-18T19:21:00.003+01:00

He preparado una presentación de introducción a las metodologías ágiles en particular y a Scrum en profundidad.
No se basa en la experiencia personal porque, tristemente, todavía no he participado en ningún desarrollo que la emplee (¡pero espero que eso cambie pronto!).
Aprovecho para recomendar muy especialmente una de las referencias: "Scrum and XP from the Trenches", un extenso (~120 páginas) y detallado documento sobre cómo aplican Scrum en una empresa.
Agradeceré enormemente cualquier crítica, corrección o sugerencia sobre el contenido de la presentación :).

12 segundos de oscuridad

2008-10-14T19:36:00.005+01:00

Te encuentras con un problema. Analizas la traza que deja la excepción. Pones puntos de ruptura y navegas por la solicitud. Te metes en las tripas del código abierto que utilizas. Sales de ellas pero dos capas más arriba hay más código abierto. No localizas el problema. Miras la documentación de referencia. Vuelves a darle una vuelta, localizas el problema, y lo solucionas.

No sólo has resuelto el problema, sino que has aprendido sobre todo lo que utilizas, y si eres algo exigente contigo mismo, cada vez lo harás más rápido.Lo importante no es el momento de iluminación en el que resuelves el error, sino los doce segundos de oscuridad anteriores. El camino es lo importante.

no es la luz

lo que importa en verdad

son los 12 segundos

de oscuridad

- Jorge Drexler

¿Pueden el iPhone y Android alterar la conquista del escritorio?

2008-10-10T16:57:00.005+01:00

Llevamos años hablando sobre la hegemonía de Windows en el "escritorio", sin que ésta haya variado sustancialmente. Aunque la cuota de mercado de cada sistema operativo es un dato muy difícil de calcular, en hitlinks podemos ver unas estadísticas para hacernos una idea al menos del orden de magnitud del que estamos hablando, y la tendencia.

En septiembre las diferentes versiones de Windows han acaparado un 89%, Macintosh un 8%, y GNU/Linux no llega al 1% (la nebulosa "otros" se lleva el 2%). En resumidas cuentas, dominio absoluto de Microsoft.
Si observamos la tendencia del último año vemos que Windows ha perdido aproximadamente un 1.6%, del cual 1.4% se va para Macintosh y un 0.3% para Linux (perdonad por los redondeos). La tendencia es levemente negativa para Windows.
Si tomamos más datos disponibles, podemos ver que la cuota de Windows apenas había oscilado desde octubre de 2006, a noviembre de 2007, con un 90.5x% en ambos, mientras que Macintosh aumentaba un 1.6%.
En mi opinión, esta tímida tendencia de diversificación se debe al iPhone. La integración entre los diferentes productos Apple es uno de los objetivos principales, y los usuarios pueden verse animados a cambiar gracias al dispositivo. Esto, unido a una siempre creciente importancia de la Red va haciendo a los usuarios menos dependientes del sistema operativo.
Siempre hemos tenido Java como herramienta multiplataforma. Ya tenemos (en beta), Air (la de Adobe, con el Twhirl como abanderado), y Mono 2.0 (la implementación libre de .NET) acaba de ser liberado. Está claro que la publicación de Chrome va en ese sentido. Tenemos también Firefox, Opera, Picasa, Google Desktop, The Gimp, OpenOffice...
¿Conseguirá la penetración en mercado del iPhone, Android y Chrome que la gran masa de usuarios se comience a plantear que hay alternativas?

Antipatrón: pensar en cambios

2008-10-02T18:52:00.004+01:00

A diario nos enfrentamos con problemas, y con frecuencia caemos una y otra vez en los mismos errores, siguiendo unas conductas que nunca llevan a nada bueno pero que nos obstinamos en repetir. La wikipedia recopila algunos de estos antipatrones. Me gustaría añadir uno que suelo ver y que también considero negativo.

En caso de error pensar qué hemos cambiado

A veces (con demasiada frecuencia) nos encontramos con que algo "ha dejado de funcionar". En mi opinión, buscar cambios es una tarea inútil:

Parte de que la premisa de que antes estaba bien, lo cual no tiene por qué ser cierto. Podría ser que nuevos datos hayan hecho aparecer un fallo que antes estaba oculto, podría haber cambiado algo en el servidor, en la configuración...
Rara vez se programa solo, así que lo normal es que varias personas pudiesen estar implicados en una misma línea.
Aún suponiendo que antes estaba bien, para comparar hay que localizar una versión correcta y analizar el cambio, y ver por qué se hizo...

En mi opinión es mucho mejor centrarse en el error para localizar el problema.

Corolario: hay que leer las excepciones, y depurar, incluso a través del código de las librerías.

Las mismas discusiones durante 33 años

2008-09-28T12:41:00.005+01:00

Estoy leyendo "The Mythical Man-Month" (TMMM para abreviar), libro de obligada lectura para todo informático.

En la estantería he ido acumulando libros cuya vigencia es limitadísima, especialmente todo aquello que se refiera a lenguajes. Por ejemplo, "Beginning JavaServer Pages" fue un muy buen libro para comenzar con J2EE, pero ya caduco, a pesar de provenir de revisar otro que apenas tendría dos o tres años. Sin embargo, TMMM está sorprendentemente vigente.

Es un libro cuya primera edición data de 1975. Contiene un conjunto de ensayos sobre el desarrollo de grandes sistemas de información, que resumen la experiencia de su escritor, Frederick P. Brooks, conocido por participar en el desarrollo del IBM System 360.

Seguramente este no sea la última reflexión aquí que genere este libro, pero ya en los primeros capítulos se puede comprobar que en ingeniería del software llevamos 33 años con las mismas discusiones.

El capítulo 2, que da título al libro, comienza diciendo que las técnicas de estimación en proyectos software son pobres, y que además confunden esfuerzo con progreso (al tomar como medida hombre y mes). Y que cuando algo va mal, nos empeñamos en meter más gente en el proyecto. No sé vosotros, pero para mí esto es el pan nuestro de cada día.

En ese mismo capítulo se habla de las pruebas, y de no contar con ellas en la planificación.

También detalla unas medidas que supuestamente demuestran que meter gente retrasa el proyecto. Esto me parece muy exagerado (concretamente, las precondiciones del cálculo me lo parecen), pero el concepto está ahí.

Las reflexiones sobre la comunicación, del capítulo 6, también son muy interesantes. Seguramente si lo escribiese hoy tendría muchísimas cosas que decir, gracias a la distribución de contenidos en red de la actualidad.

En resumen, un libro sobre ingeniería del software que 33 años después sigue siendo vigente.

PD: el capítulo 7 es genial, mostrando la Torre de Babel como el 2º trabajo de ingeniería de la Humanidad =D

El empleo en la informática

2008-09-28T11:40:00.006+01:00

La opinión generalizada sobre el empleo en informática, al menos en mi entorno, es que hay trabajo, aunque podría ser mejor y estar mejor pagado. Hoy, en El Mundo, bajo un titular que reza "¿En paro? Conozca dónde es posible encontrar trabajo pese a la crisis económica", encontramos el siguiente párrafo:

Telecomunicaciones e informática: La gestión de software y bases de datos de las compañías necesitan más técnicos de los que las facultades y módulos forman. Los puestos más requeridos son analistas, programadores y jefes de proyecto.

Que me perdonen los telecos que lleguen aquí, pero ni la gestión de software, ni la de bases de datos, ni los puestos de analistas ni programadores ni jefes de proyectos deberían ser competencia de gente formada en telecomunicaciones. Por supuesto que hay muchos telecos válidos, inteligentes, que se autoforman y que desempeñarían un gran papel en estos cargos, incluso mejor que muchos informáticos, pero igual que lo habrían hecho si fuesen ingenieros industriales, químicos, o hubiesen estudiado magisterio. Comprendo que los trabajos de informático sean a veces desempeñados por gente que no tiene ninguna titulación de informática (universitaria o de formación profesional), pero me gustaría que desapareciese esa equiparación entre telecomunicaciones e informática por defecto. Los telecos tienen sus virtudes, y serán mejores que otros en muchos aspectos, pero no son informáticos.

Dicho esto, me gustaría hablar de un amigo. Tras años dedicado a Bellas Artes, por vocación, la frustración sumada de la confrontación con el profesorado y con el mercado laboral le hace dejarlo en favor de una titulación de Informática de Gestión. Es el típico cacharrero, cariñosamente hablando: es de esos que le encanta trastear con ordenadores, destriparlos, probar programas nuevos... Ya sabe que la carrera no tiene nada que ver con eso, pero no tiene miedo. Las matemáticas no se le daban mal, y aunque no ha programado nunca no cree que vaya a tener problemas con ello, y quiere el título para trabajar. No sé si habría sido mejor dirigirse a un módulo en vez de a una carrera, pero la decisión está tomada -y le deseo toda la suerte del mundo-.

Obviamente su decisión bien tomada por la percepción del primer párrafo. Aunque el mercado laboral informático es mejorable, está infinítamente mejor que los demás. En mi opinión, si una persona quiere destacar de la marabunta de profesionales que hay en este mercado, debe potenciar los siguientes aspectos:

Autoformación: el contenido de la carrera vale como base, pero no vale para la vida profesional. Si no quieres eternizarte en cargos de desprestigiado programador junior, lee y programa por tu cuenta. Tanto en el trabajo (¡es sorprendentemente raro encontrar gente que se documenta por su cuenta, ya no digamos que lee las referencias oficiales en vez de googlear!) como en casa (menos telebasura y más leer).
Especialización: está bien poder poner veinte tecnologías en un CV, pero si todas están al mismo nivel la impresión será mala. Si te han llamado a una entrevista especialmente por una de ellas y no puedes responder a la mayor parte de las preguntas que te hagan por ella, ni se preocuparán por las otras. Hay que dominar dos o tres (bases de datos, J2EE,Hibernate, clustering...)...
...pero hay que tener versatilidad: vale, te han contratado para programar J2EE, pero si surge un proyecto para montar un CMS, no te niegues. La aptitud y la actitud para el aprendizaje son fundamentales.
Iniciativa: propón mejoras, cuida el detalle... No basta con que la aplicación funcione para que tenga éxito. Si ves que dos botones son indistinguibles, propón los cambios. Haz componentes reutilizables cuando veas elementos repetidos aunque el diseño no lo haya especificado. Si los estilos de una página son mejorables, hazlo... Si ves que una página va a ser incómoda para el usuario, dilo. Si ves que código que no has hecho tú está mal, mejóralo, y avisa a quien lo haya hecho para que lo tenga en cuenta. Las jerarquías dan igual, el desarrollo es un trabajo en equipo. Si alguien se enfada porque "un igual" le diga algo, el problema lo tiene él. "Nadie es tan pobre como para no tener nada que enseñar, ni tan rico como para no tener nada que aprender". Eso sí, no recrimines, sé constructivo.

Ojo. Me parece totalmente respetable la gente que no tiene especial vocación y que está en esto sólo porque hay trabajo. Esa gente a veces ni tiene ordenador en casa, y ni se plantea tocarlo fuera del horario laboral para otra cosa que no sea ocio. De verdad, perfecto. Pero esa gente tiene que asumir que su desarrollo profesional va a venir delimitado por lo que consiga de las empresas. Uno no se puede quejar de "lo mal que está esto" si no pone nada de su parte.

Si tuviese que organizar una empresa de informática...

2008-09-22T16:00:00.004+01:00

Vamos a jugar al "Si fuera...", con la tranquilidad que da saber que esto es un blog y que no van mis habichuelas en ello :).

Si tuviese que organizar una empresa que desarrollase aplicaciones...

Utilizaría Scrum como metodología de trabajo. Creo que las metodologías tradicionales (RUP, Metrica...) son demasiado pesadas y recargadas de documentación y burocracia. Ojo, que lo que tengo en mente son aplicaciones de gestión, "convencionales". Si tuviese que desarrollar el software de un satélite o de instrumental médico, otro gallo cantaría. Para cada situación, la mejor herramienta.
Me olvidaría de certificaciones ISO, CMMI y demás a menos que realmente me obligasen, al menos al principio. Tenerlas no garantiza realmente nada. Yo soy el primer interesado en desarrollar software de calidad, y voy a hacer todo lo posible por lograrlo. Si a lo que ya hago puedo ponerle un sello, perfecto. No quiero andar parcheando, como todas las empresas, la semana antes de una revisión.
Si tuviese que fijar una única plataforma de trabajo (es un requisito que se suele establecer en las organizaciones) sería Java, desarrollando con Seam. Hibernate es fantástico, RichFaces me parece la mejor librería JSF para Ajax... y Seam los integra y mejora.
Los desarrolladores tendríamos Eclipse, con JBossTools y otros plugins útiles como JadClipse.
En el repositorio, SVN, tendríamos los proyectos listos para construir con Maven 2.
Usaríamos Trac para gestionar los errores.
Y XWiki para la documentación a compartir (tutoriales, ayudas...).
Tendríamos un sistema de integración contínua (¿Hudson, quizá?) que nos monitorizase los proyectos, ejecutando...
... pruebas con JUnit, TestNG y/o Unitils, y...
... medidas de calidad del código como Eclipse Metrics, PMD (¡con CPD!), Crap4J, Coverage.
... pero escucharía comentarios y leería sobre herramientas para usar lo mejor posible :).

Algunas de estas decisiones se basan en la experiencia y otras por ahora sólo en expectativas. ¿Qué opináis?

Otra de mis dudas es el servidor de aplicaciones y el SGBD. En función de la escala supongo que habrá que elegir puntos intermedios desde Tomcat+MySQL hasta WebSphere+Oracle...

Diseñando una arquitectura (Apéndice): Trabajo futuro

2008-09-21T16:05:00.005+01:00

En este tiempo hemos ido dejando cosas por el camino y anotando "oportunidades de mejora". Algunas las incorporaremos en cuanto podamos, otras habrá que probarlas, otras quedarán para otros proyectos...

Todas las críticas y sugerencias adicionales serán bienvenidas, como siempre.

Objetivos:

Mejorar la productividad del desarrollo.
Reducir el desarrollo propio del framework al mínimo, maximizando el uso de herramientas open source disponibles.
Solventar o al menos atenuar las limitaciones de la plataforma (J2EE) y de JSF.
Facilitar la integración de librerías.

JSF 1.2 (+ RichFaces 3.2)

Lo primero será migrar a JSF 1.2. Este estándar está estrechamente vinculado con el servidor de aplicaciones, y hacerlo exige migrar a SJSAS 9 (o al revés, como prefieras verlo, ya que tampoco se puede usar el 1.1 en el 9). No es un gran avance en sí mismo (se espera bastante de JSF 2, hay multitud de cosas inexplicablemente mejorables todavía en la actualidad), pero llevará consigo pasar a la rama 3.2 de RichFaces, lo cual sí es una gran mejora. Nuevos componentes, mejoras muy importantes en los actuales...

JavaRebel

Tener que reiniciar el servidor constantemente es un infierno. Esta librería promete mejorar esto, minimizando la necesidad de reinicios mejorando la sustitución de clases y ficheros de configuración en caliente. Hay que probarlo.

Pruebas orientadas a datos

Probar el código de una aplicación de gestión implica conocer y manipular el estado de la base de datos. Estoy seguro de que ya hay soluciones para facilitar esto (¿TestNG, Unitils...?).

JSFUnit

Quiero poder probar a nivel de vista, y JSFUnit sirve para esto. Por ejemplo, cuando me encuentre con un problema de visualización en una página, quiero poder programar (con un coste en tiempo bajo) una prueba que demuestre que existe dicho problema, y que me sirva para comprobar que la solución efectivamente lo resuelve.

Motor de workflow

Realizamos una formación en el motor Enhydra Shark, y fue francamente decepcionante. Sí, se podía hacer lo que dice que hace, pero no ayuda a realizar una aplicación. Al elegir un componte tan fundamental en una arquitectura no me vale con que proporcione algo de valor añadido, debe ser realmente productivo. Vimos que nos iba a dar más trabajo y problemas de lo que iba a aportar, y lo descartamos en favor de desarrollar uno propio. En la actualidad lo que hemos desarrollado nos permite implementar el diagrama de flujo de un modelo a nivel de base de datos. Sin programar una línea de código nuevo podemos hacer que un modelo pase por estados, controlar a nivel de lógica de negocio la seguridad de las acciones, asignar tareas automáticamente, delimitar plazos, realizar forks y joins, declarar la seguridad a nivel de propiedad (símplemente con las propiedades rendered y displayValueOnly en los componentes JSF el sistema calcula qué campos puede ver y/o editar un usuario) y un largo etcétera. La gran ventaja de "nuestro" motor con respecto al resto, aparte de poder hacer (casi) de todo sin programar una sola línea, declarando todo en base de datos, es que tenemos componentes JSF. Mediante una simple etiqueta se pueden hacer cosas como listar las tareas pendientes, generar una botonera para ejecutar las acciones que el usuario puede hacer, mostrar el historial de la tramitación... Tener todo esto es un auténtico trabajo tangible que permite tener un flujo funcionando en una aplicación en muy poco tiempo.

El desarrollo del mismo fue por imposición, pero creo que ha sido beneficioso (suelo decir que del desarrollo propio para el framework esto es lo único realmente útil). Sin embargo, no creo que desarrollarlo desde cero haya sido lo mejor. La decisión se tomó porque ya se había perdido demasiado tiempo con el Enhydra Shark como para plantearnos otras opciones, pero estoy casi seguro de que tiene que haber alternativas mejores. Tengo jBPM en el punto de mira. Si cumple mis expectativas, mi intención es, para nuevos horizontes (no pienso reemplazar lo existente en el Framework ya), adoptarlo y ampliarlo, que para algo es open source. Por ejemplo, hacer componentes JSF que reduzcan ese salto entre el interfaz y el modelo, principalmente.

Seam

Cuando se decidió la arquitectura del framework, Seam era un proyecto prometedor pero todavía inmaduro, como han demostrado los grandes cambios y mejoras incorporados en la 2. Por ello elegimos Spring, maduro, completo, y no nos hemos arrepentido en absoluto.

Sin embargo, a estas alturas la lista de características de Seam contiene todo lo que usamos de Spring, a la vez que complementa a JSF corrigiendo sus carencias. Lo que es más, está orientado a dar "en un paquete" toda la pila de librerías, desde Hibernate a RichFaces, e integrarlas a todos los niveles. También para nuevos horizontes (estoy muy contento con el uso que damos a Spring) mi objetivo es usarlo intensivamente.

Diseñando una arquitectura (IV/IV): Conclusiones

2008-09-21T14:58:00.003+01:00

Aquí acaba el trayecto en el que he pretendido volcar prácticamente mis últimos dos años de trabajo.

IV. Conclusiones

Generales

El uso de librerías más avanzadas con el fin de aumentar la productividad exige más del programador. Cualquiera puede picar código a destajo, pero no todo el mundo tiene la misma facilidad para abstraerse y pensar en términos de capas, de objetos... No es sólo una cuestión técnica, por ejemplo, de "saber Hibernate". El uso de estas herramientas revaloriza la capacidad para trazar errores, para hacer código correctamente encapsulado, para aprender nuevas tecnologías... La aptitud de los programadores es, por tanto, más importante que nunca.

Obviamente también lo es la actitud. Entre las quince o veinte personas que se han enfrentado con el "nuevo framework" y el nuevo entorno de desarrollo hemos encontrado actitudes muy diferentes. Por ejemplo, con un nuevo IDE, los hay que en tres días se han aprendido todos los atajos para las acciones frecuentes, y los hay que dos años después siguen usando el ratón para guardar un fichero. Los hay que incluso llegan a trazar el código de las librerías en busca del error (alguno llegó a mirar código nativo de la JVM) y otros que insisten en redesplegar cuando algo no funciona, "por si acaso". Los hay que en el foro o por correo exponen el problema enseñando trazas, código, etc, y los hay que dicen "no me funciona".

La aptitud y la actitud son algo difícilmente controlable. Las medidas más importantes que se pueden tomar son mejorar los procesos de selección de personal, formación, e incentivar. En otra ocasión me extenderé más con la experiencia ganada en estos aspectos, quiero evitar otra entrada infinita como la anterior.

Entorno de desarrollo

A lo largo de casi dos años ya nos hemos encontrado varios bugs en MyEclipse, pero nada grave. Es un buen entorno de trabajo, aunque si no hubiésemos necesitado la integración de Matisse (no sé si ya habrá plugins gratuitos que lo integren, por aquél entonces no) yo me habría ceñido a Eclipse sin más. Fundamental el valor añadido que aportan otros plugins, como elJadClipse para la ingeniería inversa, o PMD y FindBugs para la calidad del código. La integración con JSF, Spring o Hibernate me parece decepcionante. Los asistentes para añadir capacidades de dichas librerías a los proyectos me parecen innecesarios y conflictivos. No está muy claro cómo decir, por ejemplo, que un proyecto ya existente "es JSF" o "es Spring", los asistentes están muy orientados a cuando se parte desde cero.

Eso sí, el detector de conflictos en el código CVS es lamentable. Especialmente cuando trabajas con varias ramas, resolver los conflictos con él es un suplicio. A veces estoy recurriendo al Araxis Merge para solventar las carencias del Eclipse en este sentido.

Tener que usar SJSAS 8 como servidor es un infierno. El problema no es los bugs que pueda tener (todas las aplicaciones los tienen), sino el soporte que existe en la comunidad open source sobre él. Las librerías están probadas y soportadas siempre sobre Tomcat y JBoss, los demás servidores sólo marginalmente. A menudo ni existe información (ni en la documentación ni en los foros) sobre otros servidores, y cuando hay suele estar obsoleta o incompleta. Además, el soporte técnico (la principal razón para utilizarlo) se suele lavar las manos cuando te encuentras con un problema, alegando que es un tema de la librería, no del servidor. En breve nos enfrentaremos a migrar a SJSAS 9, que esencialmente es el Glassfish 2, que sí es open source, lo cual supongo que mitigará el problema.

No dudo que SJSAS sea un buen servidor, con buenas herramientas de administración, clustering y demás. Mientras todo funcione no hay problema. Sin embargo, cuando aparece un error, la sensación de desamparo es tremenda.

Generalidades sobre las librerías

Cuando te bajes las librerías, bájate también el código fuente y configúralo en Eclipse al configurar las librerías. Esto te permitirá tener el javadoc del código y depurar. No es que vayas a modificar su código, pero cuando te encuentres con una excepción inesperada podrás trazar para localizar el problema. El trabajo de documentación y de tratamiento de excepciones en librerías Java de código abierto suele ser excelente, pero cuando no lo es, disponer de esto es impagable.

El trabajo de integración (incluyendo resolver los problemas que aparecen a posteriori) de las librerías de vista (MyFaces, Tomahawk, Sandbox, Facelets y RichFaces) en el SJSAS es problemático. Así como la convivencia de Spring e Hibernate es perfecta, el resto no lo es. Por favor, ¡integración de Facelets en JSF ya!

Algunos dicen que el framework tiene demasiadas librerías, pero yo opino que incluso le falta alguna. En vez de utilizar un motor de workflow existente (jBPM, Enhydra Shark...) hemos desarrollado uno propio. Si bien creo que lo hecho está muy bien, IMHO ha sido un error. Habría sido mejor tomar uno existente y desarrollar sobre él para mejorar sus carencias.

Hibernate

Ya me he expresado varias veces muy en favor de Hibernate, el cual recomiendo encarecidamente. Aquí me centraré sólo en los puntos negativos.

Hibernate no es intrínsecamente lento ni devorador de memoria (de hecho, correctamente usado incluso puede optimizar ambos aspectos), pero hay que "atarlo en corto". Es muy fácil no darse cuenta y provocar que la carga de una página genere cientos de consultas. Abstraer el acceso a datos es fantástico, pero si no se pone cuidado es fácil que se vaya de las manos.

El polimorfismo y la herencia desde el punto de vista de la programación es elegante y potente, pero genera consultas monstruosas. Úsese con moderación. Nuestro DBA me miró asustado al ver que una consulta ocupaba aproximadamente siete folios (espacio simple, fuente 11 aproximadamente :) ). Sin embargo, hay que admitir que el rendimiento de Oracle en estos casos es espectacular. Bastó con mejorar una vista (era de sólo lectura, así que "materializarla" fue una solución óptima) para que se ejecutase sin problemas de coste. Mi recomendación es exprimir Hibernate al máximo, haciendo el código lo más elegante y correcto posible, y optimizar a nivel de BBDD. Si aún así algo se vuelve lento, siempre se puede optimizar ese punto en concreto.

Algo similar a nuestros problemas con el (nulo) soporte a SJSAS ocurre con el combo Hibernate + Oracle, especialmente en la gestión de datos binarios. Sin embargo, afinando un poco con el driver y utilizando alguna mejora que ofrece Spring al respecto, no hay problema sin resolver.

JSF

Como ya hemos dicho, sólo es una base. Facelets es imprescindible (¡estándar ya!). RichFaces es una gran librería para Ajax.

Diseñando una arquitectura (III/IV): Implantación

2008-09-14T16:04:00.009+01:00

Para explicar esta etapa, la palabra es crisis. Pero no tanto la acepción extendida en la actualidad, sino el significado etimológico que recoge la Wikipedia

Coyuntura de cambios en cualquier aspecto de una realidad organizada pero inestable, sujeta a evolución; especialmente, la crisis de una estructura.

El éxito o fracaso de este cambio se producirá (no considero que ya se haya acabado este periodo de cambio) si hacemos una correcta gestión de la crisis.

III. Implantación

En este apartado expondré cómo afrontamos este cambio, los problemas encontrados y las soluciones aportadas, y también los errores. Las oportunidades de mejora quedarán para el apartado IV, de conclusiones. Me intentaré ceñir a los hechos del cambio, dejando otras consideraciones para otro momento.

Entorno de desarrollo

El cambio del entorno de desarrollo consistía en dejar la combinación JDeveloper + OC4J como servidor local y SJSAS 8.1 en entorno de desarrollo compartido y sustituirlo por MyEclipse + SJSAS 8.2 en local.

Tras muchas pruebas vimos que la integración con el SJSAS tendría que ser mediante dos despliegues: uno packaged (internamente es generación del war + despliegue) inicialmente y para redespliegues, y uno exploded (internamente es copia de binarios al directorio de despliegue del servidor). Sin uno o sin otro el servidor no se da cuenta de los cambios.

Para hacer la migración preparé un escueto manual de instalación de ambas herramientas. Un mismo día hicimos que todos los desarrolladores (programadores y analistas) hiciesen el cambio. La verdad es que llevó bastante más de lo esperado. La instalación y configuración de ambos (adecuación al entorno interno y librerías), que por mi experiencia creo que se puede llevar a cabo en menos de media hora (yo lo he hecho, con un ordenador no especialmente rápido), en algunos casos rondó las dos horas, lo cual no me parece aceptable. Sin embargo, no recuerdo que ningún problema se debiese a otra cosa que no seguir las instrucciones. Redactarlas fue principalmente un ejercicio de repaso de lo hecho, que sirviese de guión para seguir todos los mismos pasos. Antes del cambio utilicé a un compañero de conejillo de indias, lo cual me sirvió para corregir los errores de la instalación, así que la versión definitiva usada estaba completa. IMHO ni siquiera debería haber escrito nunca el manual. La práctica totalidad de los desarrolladores somos ingenieros informáticos, un buen porcentaje ingenieros superiores (o en proceso de serlo), e instalar un IDE y un servidor no debería ser algo traumático. Sin embargo, quedó de manifiesto deficiencias en la formación (sin ánimo de ofender a nadie). Se puede salir de la carrera prácticamente sin programar, sin cacharrear, lo cual hace que nuestras aptitudes prácticas estén sin entrenar. A menudo incluso cuesta discernir entre lo que es un problema en el entorno de desarrollo y lo que es un problema en el servidor. Recomendaría exigir un trabajo más conciencudo en el proyecto de fin de carrera, de forma que este sirviese al menos para conocer las herramientas que se va a emplear al salir al mercado laboral, pero como, al menos en la Universidad de Valladolid, a "la competencia" se le regala la matrícula de honor en el proyecto, pues me parecería injusto. Antes de que surjan los trolls en los comentarios, por supuesto que hay ingenieros en telecomunicaciones realmente buenos, inteligentes, válidos y trabajadores, mucho mejores que muchos informáticos, pero el hecho es que a menos que insultes al tribunal durante la presentación, en esa carrera la nota por defecto del proyecto es matrícula de honor.

Una vez superado estos ligeros problemas iniciales, el día a día con estas herramientas ha tenido un problema: los redespliegues. No es algo exclusivo de estas herramientas, pero tener que reiniciar (o incluso redesplegar) un servidor con gran parte de los cambios es una pérdida de tiempo grandísima. Pronto detectamos que la gente hacía demasiados redespliegues. A menudo cada vez que algo no funcionaba se hacía un redespliegue o un reinicio, "por si acaso". Cada uno puede llevar uno o dos minutos como mínimo, y si vas sumando al final es mucho tiempo perdido, especialmente porque el "por si acaso" nunca sirve para nada. Para evitarlo, distribuimos los casos en los que, al menos con esta combinación de MyEclipse + SJSAS 8.2, es necesario hacer un reinicio o un redespliegue:

Si se añade, quita o modifica un método o atributo, o la declaración de una clase, el propio MyEclipse avisa de que es necesario reiniciar.
Si se modifican ficheros de JSF, Spring, Hibernate, Log4J, etc, es necesario reiniciar.
Si se modifica el web.xml, es necesario redesplegar.
En el resto de casos hacer otra cosa no servirá de nada. Si hay un problema, reiniciar o redesplegar no servirá de nada, así que ¡no lo hagas!

Para mitigar este problema se optó por orientar el desarrollo, hasta la capa de servicios, hacia las pruebas. Desarrollar orientado a pruebas no exige lentos reinicios o redespliegues de servidor, tan sólo relanzarla, que es mucho más rápido (aparte de las otras obvias ventajas).

El único problema grave que tuvo este cambio en sí (los problemas en la instalación fueron más sintomáticos que realmente costosos) fue el propio servidor. Casi nada (ni libreriás open source ni productos comerciales) tiene soporte para SJSAS. Todo se orienta a Tomcat y, si el producto es de JBoss, a su servidor. Comprendo que no es lo mismo para un administrador de un cluster de servidores Sun en producción tener SJSAS que tener Tomcat, pero para el desarrollador es un opción. Y desarrollar en Tomcat y después desplegar en SJSAS no es opción. Hay incompatibilidades, así, como suena. Basta con echar un vistazo a los foros para darse cuenta de ello.

Librerías del framework

Antes de desgranar los hechos por capas, debemos hablar en general del "lote" (JSF+Spring+Hibernate). Yo no soy ni mucho menos un experto en estas tecnologías, ni disponíamos de nadie con una gran experiencia en ellas, así que mi papel era conseguir dominarlas al máximo para poder solucionar los problemas que apareciesen. Ninguno de los programadores ni analistas tenía experiencia con ninguna de ellas. Por ello en estos dos años de investigación (creo que es como se debe denominar a esta tarea) he metido las manos en harina al máximo.

Para facilitar el cambio tomamos las siguientes medidas:

Inicialmente hicimos unas sesiones relámpago de introducción a estas tecnologías. Al menos deberían servir para responder a las preguntas "¿qué?", "¿para qué?" y "¿dónde me documento?" La pena es que sólo uno de los programadores que las siguió desarrolló con ellas en los siguientes meses (y además nos dejó en poco tiempo), por lo que cayeron en saco roto.
La contratación de nuevo personal se orientó a gente con experiencia en ellas o, al menos, con experiencia de años en diferentes tecnologías. Eso provocó alguna rotación indeseada, pero puso de manifiesto que es muy difícil conseguir personal realmente formado en tecnologías "avanzadas" de J2EE. Es difícil que a la llamada de "gente que sepa de Hibernate" aparezca gente, y aún en ese caso durante las entrevistas nos encontramos con muchos casos en los que en el CV aparecía dicha experiencia pero después no se sabía ni explicar qué era una LazyInicializationException.
Creación de wiki interno con documentación, FAQ, y guía de errores.
Todas las dudas se resolverían a través de un foro en vez de mediante teléfono o correos. De esta forma todo quedaría documentado.

Sobre la formación sólo puedo decir que no lo hicimos (o no lo pudimos hacer) como se debería. No dedicamos tiempo específico a formarnos, por lo que los problemas los ibamos resolviendo sobre la marcha. Tras esta experiencia me queda claro que todo el equipo debe conocer en cierta profundidad las tecnologías implicadas, especialmente Hibernate, incluso aspectos internos de funcionamiento. Es deseable que cada proyecto cuente con al menos una persona que realmente lo domine. Durante un desarrollo aparecen problemas complejos, no sólo errores, que no tienen una respuesta sencilla. Es fundamental contar con la capacidad de afrontarlos con solvencia. No sólo hablamos de problemas técnicos, sino también problemas de concepto. No podemos aumentar la produtividad sin aumentar la complejidad, aunque sí se puede reducir el coste. Utilizar herramientas avanzadas es la principal razón de aumento de la complejidad, y no se puede suponer símplemente que adoptando nuevas tecnologías se va a mejorar el proceso. Esta adopción requiere una gestión, especialmente en formación, y tiene un coste inicial. Y en este caso no basta con aprender sobre la marcha. Eso no es productivo. Es imprescindible pararase a aprender inicialmente antes de empezar a desarrollar.

Hibernate

Hibernate me sigue pareciendo sencillamente impresionante. Como con cualquier otra tecnología hay un coste de aprendizaje y todavía tiene algunos bugs y problemas, pero sigo opinando que no hay razón para no usarlo. Es una tecnología ya madura y contrastada.

Al emplear Hibernate hay dos problemas a solucionar: la formación del personal y problemas de integración con el SGBD específico. El primer punto está ya cubierto en el apartado anterior. Sobre el segundo, surgen problemas en la combinación de Hibernate y Oracle. El driver de Oracle, según los desarrolladores de Hibernate, está plagado de bugs. Es especialmente conflictiva la gestión de binarios (blobs, clobs...). Recomendaciones al respecto:

Lo primero es fijar el driver de Oracle. Localizar cuál es el que funciona en nuestro entorno (en los foros de Hibernate se habla al respecto) y agarrarnos a él sin soltarlo. Nada de actualizarlo.
Para solucionar los problemas con los blobs, Spring aporta el OracleLobHandler que te hace olvidar los bugs que aparecen al combinar Oracle con Hibernate.

Otras sugerencias aprendidas:

Usa Hibernate Validator para todas las validaciones de usuario. ¡DRY!
Usa Hibernate Annotations para configurar el mapeo relacional, mucho más cómodo que la configuración XML.
No te intentes adherir a EJB 3.0. Tiene limitaciones (consulta la documentación de Hibernate Annotations) con las que tarde o temprano te vas a encontrar.

Por último, en mi opinión, al contar con una herramienta así merece la pena cambiar la forma de afrontar la creación del modelo de datos. Tradicionalmente, el analista debe crear el modelo de datos para soportar los datos, el cual será transformado por el diseñador en un modelo físico de datos, un modelo de tablas y relaciones entre ellas que utilizará la aplicación. Sin embargo, esto ni es cómodo ni encaja bien a la hora de trabajar con Hibernate. Aunque los puristas supongo que me desollarán por lo siguiente, creo que hay que olvidar la creación del modelo de datos y pasar diréctamente al modelo de clases. No hagas diagramas. Haz diréctamente clases, y anótalas con @Entity, Hibernate hará el resto. Si puedes, utiliza claves surrogadas en vez de complejas claves compuestas. Con esto no quiero decir que no haya que tener en cuenta principios semejantes a los que se usan al crear el esquema de datos. Símplemente veo más operativo generar el esquema a partir de las clases en vez de trabajar en hacer el esquema y después verse encorsetado por él a la hora de programar.

Spring

No recuerdo ni un sólo problema real con Spring. Así como nuestra "guía de errores y excepciones" tiene infinidad de entradas en el apartado de Hibernate, ya que la transición de hacer SQL a mano a pasar a Hibernate es bastante compleja, la de Spring creo que está vacía. Usamos el módulo de IoC, el de seguridad, la gestión transaccional (programáticamente), y los añadidos que tiene para integración de otras librerías (Hibernate, servicios web...), al menos explícitamente. Ni siquiera la formación supuso un problema, ya que una vez se tiene organizado y configurado, basta con saber añadir e inyectar los beans en los xml para usarlo.

Es cómodo, útil, completo y maduro. Premia buenas prácticas y además aporta valor añadido, como publicación de servicios, inicialización de beans o planificación de tareas (mediante integración con librerías externas). Como queda claro, apuesta por la integración (lo cual queda claro cuando ves sus dependencias).

Lo único que lamento es la deficiente integración en el IDE (autocompletar es mejorable, escasa detección de errores) y que exija reiniciar el servidor al hacer cambios (cosa que tampoco ocurre tan a menudo).

JSF

Este no es el momento para criticar JSF, pero es imprescindible hacer una puntualización: JSF no es un framework completo, sólo es una base (mejorable) sobre la que usar otras cosas. Si pretendes usar sólo lo estándar, no estás comprendiendo su finalidad.

Optamos por MyFaces + Tomahawk + Sandbox + RichFaces + Facelets. Hacer funcionar todo esto sobre SJSAS 8.x no es una tarea trivial.

Sobre la versión 8 del servidor no se puede usar JSF 1.2, estamos limitados a JSF 1.1.
El servidor de aplicaciones trae su propia implementación, y no usa la de la aplicación símplemente con incluirla. En el wiki de MyFaces hay más información al respecto.
Hacer componentes con "trozos de página", algo utilísimo para reutilizar código a nivel de vista, sólo con JSF es una tarea hercúlea. Como mínimo, tres clases más la configuración en el faces-config. Para mitigar esto hay que usar Facelets (imprescindible, creedme).
Facelets exige tener un taglib de las librerías usadas, no basta con el tld que ya tienen. De las librerías open source habituales hay taglibs disponibles, pero tenemos alguna librería propietaria que no lo incluye.
Nula gestión de excepciones.
Los errores a veces son crípticos. Facelets mejora algo esto, pero tampoco demasiado. Además, a veces aparecen problemas rarísimos de identificadores duplicados, solicitudes que se repiten, etc., sobre los que no hay respuesta clara.
Incompatibilidad entre navegadores. Lo habitual es trabajar en Firefox (por FireBugs y Web Developer Toolbar) y probar después sobre Internet Explorer, y es raro no llevarse sorpresas.
Olvídate de los editores gráficos. No merecen la pena. Ni para los ficheros de configuración, ni para las páginas, ni para nada. Codifica. Escribe cada línea de tu código, no pierdas el tiempo con vendedores de humo. Deja los editores gráficos para los diseñadores, los desarrolladores debemos manejarnos entre código.

Aún con todo esto, RichFaces me parece una buena razón para usar JSF. Uno de los objetivos del cambio es incorporar Ajax al interfaz, y la forma en la que afronta esta librería este problema es muy buena, la mejor posible en JSF. Sus componentes son buenos, pero ya sólo el a4j:support justifica su elección. Permite añadir Ajax a cualquier página JSF existente. "It just works". Nos hemos ido encontrando con bugs y problemas, pero el trabajo que se está haciendo en ella es muy bueno, y el soporte en el foro, también. Además, perfectamente documentado (en amplitud y profundidad), no como Dojo y otras tantas. Áltamente recomendable.

Pruebas

Las pruebas de una aplicación web de gestión tienen varios problemas intrínsecos: el estado de la base de datos, el perfil del usuario en sesión, y probar el interfaz.

¿Cómo podemos probar si una búsqueda filtrada paginar funciona si no sabemos si hay datos? La solución que hemos adoptado en estos casos es combinada. Por un lado, podemos consultar el estado actual de la base de datos. Por otro, modificamos su estado para hacer la prueba. Por ejemplo, ¿cómo saber si funciona el listado de 'tareas pendientes'? Primero consultamos las tareas pendientes de un usuario. Después hacemos una inserción que genere una tarea pendiente. Después hacemos otra consulta y comprobamos que hay una más de las que había antes. Por último, limpiamos lo insertado. Esto tiene dos problemas (al menos). La prueba es más compleja, aunque realmente no es un problema, porque como haremos una prueba de búsqueda y otra de inserción no tenemos más que programar una tercera que combine ambas, por lo que el coste de programar las pruebas apenas aumenta. Sin embargo, al hacerlo estamos metiendo una gran dependencia entre las pruebas, y eso es incorrecto.

Con el perfil del usuario el problema es similar. A menudo estamos obligados a asegurarnos de que existen usuarios con el perfil deseado, lo cual exige más control sobre el estado de la base de datos.

Tengo pendiente estudiar soluciones a este problema. Creo que TestNG y/o Unitils incorporan soluciones a esto, pero no he podido probarlo. De todas formas, siempre tendremos que especificar un estado concreto, con lo cual no estamos probando el sistema en cualquier caso, sino sólo en el especificado. Esto nos lleva a la discusión de cuánto probar, en la que no entraré en este momento :).

Para probar el interfaz por aquél entonces había alguna alternativa, pero demasiado costosas para mi gusto. BadBoy y Selenium añaden funcionalidad de prueba al navegador, pero preparar las pruebas sigue siendo costoso. Reciéntemente ha aparecido JSFUnit, que todavía no he podido probar.

Hasta aquí la exposición de los hechos de los últimos años. Ha acabado siendo un conglomerado de problemas, apaños (¿por qué usar el término 'workaround' teniendo alternativas propias?), opiniones y decisiones, pero en el fondo es de lo que se compone la experiencia diaria. Próximamente, las conclusiones, y seguro que otros posts que amplíen problemas aquí enunciados.

Espero con avidez los comentarios y críticas sobre todo esto. Estos dos años están siendo un proceso de aprendizaje del que esta entrada es sólo un paso más.

Diseñando una arquitectura (II/IV): Alternativas de solución

2008-09-10T00:24:00.004+01:00

Estaba claro que la situación era mejorable. La industria llevaba años generando grandes productos que no se estaban aprovechando. Ahora era el momento de elegir e implantar.

II. Alternativas de solución

He de agradecer que se confió en mí plenamente -espero que no haya habido demasiados arrepentimientos sobre esto-. Se me exigió informes, pruebas de viabilidad, etc., pero la libertad de la que disfruté fue máxima. Se mantuvieron las siguientes restricciones:

El entorno sería J2EE. Java es con lo que se trabaja en todo el departamento, y así iba a seguir siendo. Esto favorece la movilidad de personal, facilita la formación, la reutilización de código, etc.
El SGBD sería Oracle. Es lo que se ha venido usando siempre, es de lo que se cuenta con personal cualificado, soporte, etc.
El servidor de aplicaciones sería el Sun Java System Application Server 8.1. Esto viene impuesto por la superorganización.

Entorno de desarrollo

Lo primero fue cambiar el entorno de desarrollo. Se venía usando JDeveloper por inercia, por ser lo utilizado en la superorganización, pero no respondía a ninguna restricción real. La principal razón a la que nos agarramos para el cambio fue el servidor de aplicaciones. El JDeveloper integra OC4J y no había forma de hacerlo funcionar contra el SJSAS 8, que era lo deseable. Además, para cualquiera que haya usado otro IDE el OC4J es antediluviano. Aunque sobre el papel las características sean similares, en el día a día deja mucho que desear.

La política de la empresa es tender hacia el Open Source y a evitar gastos innecesarios, así que se barajó Eclipse y NetBeans. El primero es al desarrollo como Firefox a los navegadores: cuenta con infinidad de plugins útiles. El segundo, sin embargo, tiene un killer, Matisse. Una buena parte del desarrollo se hace en aplicaciones standalone de escritorio, con swing, y al parecer Matisse es infinitamente mejor que otros diseñadores gráficos. Yo ni los había usado ni los iba a usar, y la decisión no me correspondía. Los responsables de ello lo querían a toda costa, pero también deseaban Eclipse, debido a ciertos plugins. Tras descartar usar dos entornos diferentes, se optó por MyEclipse. Este entorno es Eclipse con ciertas mejoras desarrolladas específicamente para él, e integra Matisse, por lo que era una solución ideal. El coste es muy bajo y las primeras pruebas resultaron satisfactorias, así que fue el elegido. Eso nos permitió trabajar con el servidor adecuado, además de disfrutar de todo lo que se desarrolla para él.

Persistencia

Hibernate me parece LA razón para desarrollar en Java. Es potente, flexible, completo, eficiente... Desde que lo usé por primera vez no se me ocurre comenzar un desarrollo sin él. Escribir SQL por defecto me parece algo totalmente atrasado e indeseable. Está claro que en ciertas ocasiones es lo mejor y se debe recurrir a ello, pero la potencia de poder guardar y recuperar árboles de información completos sin necesidad de escribir una consulta es inigualable. No sólo por el hecho de escribir las consultas, sino porque el no tener que escribirlas hace que no haya que modificarlas ni mantenerlas nunca. Esto, que parece perogrullo, no lo es. Si has escrito las consultas, un cambio en el modelo es dramático. Hibernate hace que ni siquiera sea necesario pensar en el modelo de datos. Piensa en el modelo de clases, piensa en términos de objetos, que es lo que la aplicación va a manejar en último término.

A día de hoy la aplicación que ha servido de arranque a esta nueva infraestructura gestiona datos de unas 140 tablas de varios esquemas, tanto propios como comunes. Sin Hibernate esto no habría sido posible.

Toplink es una alternativa similar, pero por lo que pude leer, más limitado. Se ciñe más al estándar (o el estándar a él), asumiendo ciertas limitaciones que Hibernate se salta mediante extensiones propias.

Hay otros motores diferentes que también son viables, notablemente iBatis. Sin embargo, la productividad que se obtiene no tiene nada que ver.

Unido a Hibernate se adoptaron otros proyectos hermanos: Hibernate Validator e Hibernate Annotations. El primero permite definir validaciones mediante anotaciones en los modelos, y el segundo, incorporar la configuración de persistencia en los propios modelos.

Middleware

Por aquél entonces la elección natural era Spring. Era ya un framework completo, estable, probado... Google sacó su Guice más tarde, y Seam acababa de nacer. Spring nos resolvería la organización de la capa de lógica de negocio, simplificaría las pruebas, servicios web...

El uso de Spring nos llevó además al uso de Acegi (ahora llamado Spring Security) como sistema de seguridad. Este, a su vez, a instalar un servidor CAS. Todo esto nos ha permitido implantar un sistema de single sign on del que se llevaba hablando mucho tiempo.

Pruebas

Con las pruebas tiramos por lo directo: JUnit 4. Había oído hablar de otras alternativas, pero hasta la fecha en la organización no se programaban pruebas en absoluto, así que nos contentaríamos con que consiguiésemos acostumbrarnos a usar este sistema con cierta soltura.

Adicionalmente pronto vimos que sería conveniente el uso de Unitils. Por aquel entonces Spring no soportaba JUnit 4 correctamente, y esta librería facilitaba la inyección de los beans.

Vista

Otra de las grandes justificaciones para el cambio fue la introducción de Ajax, como valor añadido para los usuarios. De nada nos serviría hacer mejor "las tripas" de la aplicación si el usuario no veía novedades.

IMHO (como siempre ;) ) si piensas en Ajax en Java tienes que pensar en JSF. Al menos por aquél entonces. En mi opinión, el planteamiento de orientación a componentes de JSF lo hace perfecto para esa tecnología. Para explicar esta opinión, siempre hablo de Struts como división "vertical" y JSF como "horizontal". Lo natural es que una solicitud en Struts vaya a un Action que realice un procesamiento y muestre una página (imagino esta generación del código como un proceso de arriba a abajo). En JSF, sin embargo, "trozos (horizontales) de página" tienen entidad propia. Tienen comportamiento y orígenes de datos propios. Está claro que con ambos sistemas se puede hacer, y de forma correcta, pero por aquél entonces parecía que lo más adecuado era JSF.

Como implementación del estándar se optó por MyFaces, debido principalmente a que un componente (que posteriormente se descartó), FCKFaces, dependía de él. Sobre MyFaces usamos también Tomahawk y Sandbox, que incorporan componentes interesantes. Pronto quedó claro que Facelets era una decisión obligada al hacer JSF (aunque nunca he dejado de echar de menos Tiles, que junto al Validator me parecían la verdadera razón para usar Struts). Para hacer pseudocomponentes con "trozos" de páginas es muy útil, y también para organizar las páginas como plantillas (aunque no es ni de lejos tan potente como es Tiles). Todo esto estamos hablando de JSF 1.1, debido a la versión del servidor.

La gran duda vino a la hora de elegir la librería Ajax. Tras dar tumbos entre varias opciones quedó claro que había dos grandes contendientes: Ajax4JSF (con RichFaces) e ICEFaces. ICEFaces tenía un conjunto de componentes mayor, más completo. Por el contrario, Ajax4JSF me parecía más flexible. Ambos tenían una intensa actividad. El ritmo de mejoras de Ajax4JSF parecía mayor, debido principalmente a sus obvias carencias respecto a la competencia (ni tenía un componente de calendario por aquél entonces). Ambos estaban bajo la tutela de JBoss, así que la continuidad parecía garantizada. A la hora de probarlos, éste no me dio ningún problema al combinarlo con otras librerías, mientras que ICEFaces sí. Al ser incompatibles entre sí, opté por el primero, aunque ICEFaces seguramente también habría sido una decisión válida. Para las cosas en las que estas librerías se quedaban cortas las completamos con componentes hechos con Facelets encapsulando código de Dojo.

Por tanto, íbamos a pasar de JDeveloper con OC4J y servlets a la vieja usanza a MyEclipse sobre SJSAS 8.1 y Oracle, desarrollando con Hibernate, Spring, JUnit, JSF y Ajax4JSF/RichFaces. Está claro que el cambio iba a ser grande. En la siguiente entrega iremos recapitulando sobre los problemas que nos han aparecido al hacerlo, los aciertos y los errores.

Diseñando una arquitectura (I/IV): Estudio de la Situación Actual

2008-09-08T10:15:00.009+01:00

Hace aproximadamente año y medio me embarqué en lo que ~~está siendo~~ ha sido mi experiencia profesional más compleja, importante e interesante: mejorar la forma de desarrollar aplicaciones web de una organización. Es un buen momento para mirar atrás.

Lo haré en cuatro entradas:

I: estudio de la situación actual (actual por aquél entonces, claro).

II: selección de las alternativas de solución.

III: implantación de la solución.

IV: conclusiones.

0. Antecedentes

En los últimos años había estado trabajando con tecnologías J2EE, tanto profesionalmente como "en casa", para proyectos propios. Anteriormente había hecho alguna cosa en PHP, y me gustaba mantenerme al día de las novedades de la industria (RoR, Phyton...), aunque no le pudiese dedicar tiempo en profundidad. En general, todo para, en mayor o menor medida, aplicaciones de gestión de datos (quien esté buscando sistemas de tiempo real o simuladores aeroespaciales me temo que tiene que cancelar su suscripción a este sitio).
De esta experiencia formé una serie de axiomas que suelo tomar como ciertos (aunque al estudiar informática la conclusión que te queda es que la única respuesta que siempre es válida es 'depende'):

La separación entre capas es una Cosa Buena:

Debe haber una capa de acceso a datos "tonta", que no tome decisiones y que símplemente sirva para acceder a bases de datos. Debe tener esencialmente 4 métodos (buscar, insertar, actualizar y borrar), salvo añadidos por eficiencia.
La capa de lógica de negocio, por encima de la de datos y por debajo de la de presentación, es en la que se programa todo lo que aparece en las especificaciones, desde el flujo de la aplicación al control de datos ("quién puede ver/editar qué en cada momento").
Las dependencias van hacia abajo, los datos hacia arriba.

No te repitas (DRY).

Corolario: no cortapegues (mejor: ¡¡NO CORTAPEGUES!!).

Para aplicaciones pequeñas, PHP o RoR o similar, para aplicaciones grandes, J2EE.

Por favor, no empecemos un flamewar aquí. Ya sé que Flickr, por ejemplo, es PHP y un montón de ejemplos más. Sin embargo, intenta hacer consumir a algo que no sea Java o .Net unos cuantos servicios web de terceros y verás lo "estándar" que son. Sí, con PHP puedes hacer OO y otro buen montón de buenas prácticas, pero si ya es difícil mantener el código bajo control con Java, no quiero ni pensar lo que ocurre con otros. Por no hablar de las herramientas, claro... Fin del tema :). Para discutir sobre esto, otro día :).

Hacer páginas con etiquetas es bueno (claridad, uso de librerías de componentes...), meter código Java en las JSPs es malo: inmantenibilidad, dificultad para trazar errores...
Ajax es bueno, hecho con Javascript a mano puede no estar mal, pero si tienes una librería que te lo proporcione es mucho mejor.

Esto tiene un corolario: ajaxificar los datos (posiblemente) es más eficiente, ajaxificar el interfaz es (posiblemente) más productivo. Escribir Javascript a mano (o con con Dojo, por ejemplo) suele llevar a hacer solicitudes Ajax que devuelvan datos. Esto consume menos recursos. Sin embargo, usar librerías de servidor (Ajax4JSF, ICEFaces...) suele llevar a que lo que se solicita son "trozos del interfaz". Esto no es siempre cierto (GWT, por ejemplo, es una excepción) pero era lo más habitual por aquel entonces.

I. Estudio de la situación actual

Corrían finales de 2006. Struts (Action, 1) comenzaba a ser considerado demodé, y Ajax era lo que tenías que decir en una entrevista si querías atraer la atención. JSF seguía con su mala salud de hierro, como ahora. Una miríada de frameworks web (Spring Web, Wicket, Web Works, Tapestry...) esperaban que comenzase a morir de verdad para regodearse sus despojos. Microsoft, tras la guerra con Sun, había publicado .NET, y la pregunta entre todos los encorbatados era ¿J2EE o .NET?. Dojo era la librería Javascript por excelencia, con sus estándares de no documentar (y si documentas, hazlo mal, sin actualizar y sin completar). Si querías mantener una conversación geek tenías que saber que lo cool era Ruby On Rails, que Google había roto todas las convenciones con GWT.

Al llegar a la nueva organización me encontré con una situación... poco habitual. Mientras el resto del mundo se empeñaba en optimizar la productividad y mejorar la calidad del desarrollo mediante librerías Java, o diréctamente renegaban del mundo J2EE para salir a otras alternativas, allí se seguía desarrollando como hablaban los manuales de 5 años atrás: servlets y JSPs (¡o sólo JSPs!). Estamos hablando de un entorno con grandísimas restricciones y los responsables de la arquitectura de las aplicaciones estaban en gran medida con las manos atadas. La superorganización (la casa matriz, la "nave nodriza", aquellos de quien dependíamos) imponía su ley (muchos, en mi modesta opinión, debidos al síndrome NIH), con sus problemas:

Desarrollo con una versión bastante antigua de un IDE:

El cliente CVS era muy malo y problemático. Eso no era un problema para la superorganización porque ellos no usaban ningún repositorio de código para trabajo compartido (así hasta el 2008, increible pero cierto), pero sí para nosotros, y eso nos hacía tener que usar un cliente externo.
Desarrollábamos sobre el OC4J integrado, que no era el de producción.

Servidor propietario, por lo que al no ser libre apenas hay documentación ni soporte sobre él.
Uso de framework propio:

Clases que generan código html (había que hacer cosas como new DropDown() en las jsps).
Diseño en una capa (todo en JSPs), llegando al extremo de programar SQL en las JSPs.

Aquí hay que decir que en la organización se hizo un diseño MVC que simulaba la estructura de Struts, de forma que nuestras aplicaciones sí seguían dicho patrón (aunque las de la superorganización no).

Wrappers para clases existentes (un envoltorio, por ejemplo, para Connection, que impide obtener el objeto propiamente dicho. En resumen, envoltorios limitados de clases existentes.
No disponíamos del código fuente.
Documentación sin actualizar.
Ninguna librería "estándar": ni siquiera Log4J, así que ni hablar de cosas como Hibernate, Struts, Commons-X...
Dependencia (oculta, sin documentar), de variables de sesión.
Las aplicaciones sólo funcionaban en Internet Explorer.

Estas restricciones habían llevado a otras malas prácticas adicionales:

Se repetía muchísimo código, por una mezcla de los problemas y restricciones impuestos y descuido propio. Ejemplos:

Las clases de acceso a datos tenían tantos métodos de consulta como páginas, así que la separación entre capas era pobre.
Cortapega entre páginas en vez de inclusión.
Cortapega entre clases en vez de agregación o herencia.

Muchas validaciones de datos de usuario (sólo) en Javascript.

Como podéis imaginar, la situación actual chocaba frontalmente con mi visión del desarrollo de aplicaciones web (y de la informática en general). Conviví con todo esto en el desarrollo de una aplicación, en papel de analista. Es cierto que las cosas iban saliendo así, pero no creo que esta fuese la mejor forma de hacerlo:

Se genera código de mala calidad, inmantenible. Seguramente este problema habría sido mucho mayor de no ser porque la naturaleza de muchas aplicaciones desarrolladas era casi de usar y tirar, con un ciclo de vida muy corto (uno o dos años de vigencia). Sin embargo, por ejemplo, la aplicación con la que comencé ya está sufriendo estos problemas. Comenzó con el objetivo de ser una aplicación pequeña y simple y desarrollada rápidamente, y las mejoras que se le están metiendo están provocando problemas que no tendríamos con otro tipo de desarrollo.
Todo se hace a medida para cada ocasión (lo más sangrante es escribir una SQL para cada situación, un simple cambio de nombre de una columna podía llegar a ser un cambio dramático).

Tras esta primera aplicación se me dio la oportunidad de hacer una propuesta de un diseño nuevo, una nueva arquitectura para nuestras aplicaciones partiendo de cero, una nueva forma de trabajar. Este será el contenido de los siguientes posts. Como anticipo del último, puedo decir que estoy satisfecho con las decisiones tomadas, pero no del todo con los resultados, así que hay que recapitular en qué cosas hemos hecho mal. Podéis también ir imaginando el contenido del post siguiente al último ;).

Google Chrome: primeras pegas

2008-09-02T21:47:00.002+01:00

Micropost con las primeras pegas:

Obviamente no soluciona el handicap de que Windows esporádicamente se congele y no puedas ni moverte entre ventanas, por mucho que sean procesos independientes.
No es Firefox, así que no tienes las extensiones. De hecho, por ahora no admite extensiones.
No encuentro que se pueda ver a pantalla completa. Ni F11, ni CTRL/alt/shift+f . La ayuda no devuelve nada por "pantalla completa", ni la lista de atajos.
A priori me gustaba más el uso de motores de búsqueda de Firefox, con CTRL+arriba/abajo. De las opciones existentes la primera no me convence porque me exige poner el nombre del buscador, y la segunda porque me obliga a personalizar y aprender palabras clave. Habitualmente tengo unos diez motores, no más, y moverme entre ellos con el cursor es suficientemente rápido.

Un último apunte:

Con Shift+Esc se puede ver el administrador de tareas, para gestionar los procesos. En estos momentos GMail me consume 31MB, lo mismo que el incremento que noto en Firefox cuando lo abro.

PD: mil perdones a los que se han ofendido por el spam en meneame ;)

Google Chrome: segundas impresiones

2008-09-02T20:33:00.007+01:00

Segundas impresiones

1.- La tendencia a quitar el tradicional menú de opciones me descoloca, son muchos años conviviendo con él. La solución que aportan las aplicaciones de Microsoft, que aparezca al pulsar Alt, me sabe a chapuza, y me parece que las ventanas son poco más que skins. Chrome ha optado por botones en un lateral. Más elegante, pero hay que acostumbrarse para no tener que buscarlo. La ganancia en limpieza merece la pena, de todas formas.

2.- El historial es una pestaña, las descargas otra... y todas con buscadores.

3.- Las opciones no dan mucho de sí. Las mínimas e imprescindibles. Menos que Firefox o Internet Explorer, muchísimas menos que Opera.

4.- La sensación es "Safari meets Google": apariencia limpia, eficiente.

5.- Han respetado los atajos de Firefox :).

6.- La omnibox muestra resultados más elaborados que la tradicional sugerencia ordenada alfabéticamente. Supongo que cuanto más se use, más útil será.

7.- nhpatt, un amiguete, me sugiere esta prueba: http://nontroppo.org/timer/progressive_raytracer.html. Chrome acaba el full render en 19.22 segundos, Firefox en 667 (habría que hacer muchas pasadas para ser estrictos, pero nos permite hacer una idea del orden de magnitud de la mejoría). Por supuesto, el resto de pestañas en Firefox no están operativas, mientras que en Chrome sí. PD: nhpatt me pasa una media, tras 10 pasadas, de unos 14.8 segundos, con poquísima desviación (menos de un segundo). La media de Opera en esas condiciones es de 17 segundos aproximadamente.

8.- Me ha importado la configuración de buscadores personalizados (lo uso muchísimo), hasta el punto de que el omnibox me está usando un traductor para buscar. He tenido que editar la configuración de buscadores. El método del Firefox de alternar entre ellos pulsando ctrl me parecía comodísimo, lo que cuentan en la ayuda no me parece tan claro. Ya veremos...

PD: conclusiones de hoy:

Mientras era (probablemente justamente) trolleado en meneame (por autopostear una noticia basada en los primeros cinco minutos con una herramienta) he seguido probándolo y va realmente bien. Ningún problema con ninguna página. Estoy con el video de la presentación, mientras abro de golpe unas veinte pestañas (10-30MB cada una), y todo funciona maravillosamente bien. Esto son sólo unas primeras impresiones, pero no pueden ser mejores (con la salvedad de los motores de búsqueda, estaba muy cómodo con los de Firefox, hay que ver los nuevos más en profundidad).

Primeras impresiones con Google Chrome

2008-09-02T20:22:00.001+01:00

Primeras impresiones:

Se ha descargado e instalado sin problemas en un visto y no visto, importando mi configuración de Firefox.
Tengo tres pestañas (la de inicio, la de presentación y esta con blogger), y 4 procesos. En total consumen aproximadamente 95MB. Firefox, con lo mismo, 60MB. En el comic ya advertían que el modelo una pestaña-un proceso tendría más sobrecarga inicial. A mí me vale si no acaba ocupando lo que ocupan el resto (¿he oído Internet Explorer?) una vez he cerrado todas.
El look de las ventanas es Vista... pero optimizando. Nada de bordes laterales o inferiores, y las pestañas se colocan en la barra del título, que es más pequeña que la estándar en XP. Muy limpio.
La página de marcación rápida contiene tanto enlaces frecuentes como las últimas búsquedas.
El Organizr del Flickr va MUY rápido, y se nota que no provoca que el resto del navegador se arrastre... El Javascript es la clave y la razón de ser de Chrome, está claro...
Moverte entre pestañas no es rápido, es instantáneo.
El Flash funciona desde el primer momento. La página del Marca nunca ha estorbado menos.

Esto para abrir boca, en breve, más...

Google Chrome: el sistema operativo de la web

2008-09-02T18:53:00.005+01:00

Todos sabemos que un navegador no tiene nada que ver con el concepto tradicional de sistema operativo, pero si las aplicaciones siguen la tendencia de ponerse en la web el navegador será la plataforma de ejecución de nuestras aplicaciones.
Ese es el motivo por el que Google (va a) publica(r) Chrome, y lo dejan entrever en la página 4 del comic promocional: "we're applying the same kind of process isolation you find in modern operative systems".
El comic enseña otras cosas interesantes:

Al compilar el navegador un bot lo prueba contra "millones de páginas". ¿Os imaginais unas pruebas que tengan como entrada posible ~~la web entera~~ las n millones de páginas más usadas?
Han hecho una máquina virtual Javascript que es un compilador JIT a código máquina.
La 'omnibox': aplican el conocimiento aprendido de cómo la gente usa el buscador para renovar cómo funciona la barra de urls. Tiene pinta de ser terriblemente simple y terriblemente útil.
Modo "sigiloso" para no dejar traza de lo que se hace.
Colleja al modelo de seguridad de Vista, que permite leer hacia arriba en los niveles de seguridad, a pesar de lo sensible que sea la información. Chrome, sin embargo, no se basará en niveles predeterminados, sino en lo que el usuario solicita explícitamente. De nuevo se comparan con un SO, no con un navegador.
Aislamiento a los plugins en un proceso aparte.
Listas negras.
Las mejoras desde el punto de vista del desarrollador las van a seguir integrando en Google Gears, que Chrome incorpora. Así, este puede que vaya a ser el mejor navegador, pero Gears seguirá mejorando todos. Pero claro, si Chrome ofrece un rendimiento que los otros no tienen, o mejoran o Gears se arrastrará en ellos...
En la página 36 dejan claro que creen en el Open Source, no en los estándares (al menos no como "unificadores"). Traducción personal: "los estándares son una forma de ayudar a todos los navegadores a ser mejores. El equipo ha hecho cosas interesantes en velocidad, estabilidad, interfaz de usuario, como la nueva página de pestañas. Algunas se pueden convertir en estándares, otras no. Pero como todo es open source, los desarrolladores de los otros navegadores pueden coger lo que quieran".

En mi opinión esto es cierto... en parte. Si se "desestandariza" lo que hacen los navegadores (en la práctica eso ocurre), las páginas no se comportan igual. Sin embargo, IMHO es el planteamiento correcto. Los estándares, en la práctica, son lentos y sometidos a burocracia e intereses particulares.

A ver qué nos depara... Leer el comic me ha dado una gran envidia. ¡Cómo debe ser trabajar en Google ampliando los límites de la web en vez de maltrabajar con sus limitaciones!

Idea Peregrina #2: conectar la red de un avión a Internet

2008-01-10T16:55:00.000Z

Leo vía Barrapunto una noticia en Wired que dice que hay una potencial vulnerabilidad en los Boeing 787 porque ¡la red que proporciona Internet a los pasajeros está conectada con la de control del avión!

The computer network in the Dreamliner's passenger compartment, designed to give passengers in-flight internet access, is connected to the plane's control, navigation and communication systems, an FAA report reveals.

Por amor de Dios... Nos hacen descalzarnos antes de entrar un avión ¡y luego conectan su red de control a la de los usuarios, que además se conecta a Internet!
Ni firewalls, ni medidas de seguridad, ni nada. Eso es un sinsentido. ¿Para qué? ¿Quién permite algo así?

Fracaso académico en Informática en la Universidad de Valladolid

2007-12-20T06:44:00.000Z

Leo hoy en el Norte de Castilla que la "lista negra" de fracaso académico en la UVA está formada por 6 asignaturas, 4 de las cuales de Informática y una de Telecomunicaciones:

(...) las asignaturas que deben ser objeto de especial atención (por sus bajos índices de rendimiento y de éxito prolongados en el tiempo), son apenas media docena, todas ellas de carreras técnicas: Economía de la Empresa (de Informática de Gestión del Valladolid); Fundamentos Matemáticos de la Ingeniería (de Ingeniería Técnica Agrícola, especialidad Industrias Agrarias), Matemáticas I (de Ingeniería Técnica de Telecomunicación, especialidad Sistemas de Telecomunicación); Matemáticas I (de Informática de Gestión de Valladolid); Matemáticas III (de Informática de Gestión de Segovia) y Matemáticas III (de Informática de Gestión de Valladolid).

Para los que no estén familiarizados con la nomenclatura de las matemáticas en la UVA, Matemáticas I es de fundamentos (lógica, conjuntos, etc.) y Matemáticas III, Cálculo.
¿A qué se puede deber este sonado fracaso en estas asignaturas? Yo creo que cuando hay fracaso generalizado en algo se puede deber a dos razones:

Las personas implicadas son generalizadamente más torpes: esto parece improbable, porque aunque la nota de corte en los últimos años ha bajado, haciéndolo por tanto el nivel de exigencia, esto es algo que está ocurriendo en la mayoría de las titulaciones por falta de solicitudes.
Las personas implicadas no trabajan lo suficiente (en relación al grado de exigencia). Esta es la razón más plausible, por una total falta de motivación. Yo he ~~sufrido~~ vivido el tránsito por esas asignaturas y es francamente descorazonador. Casi todos los que pasamos por ellas siempre comentamos lo mismo: ¿para qué tantas matemáticas en informática? En los dos primeros cursos tenemos Matemáticas I, II y III, Fundamentos, y Estadística. Cinco asignaturas de tamaño máximo que exigen más esfuerzo que todas las demás asignaturas juntas, convirtiéndose en criba y lastre para muchos durante años.

Las matemáticas son el origen y el corazón de la informática (de la computación, como les gusta llamarlo a algunos), pero ¿realmente es justificable tamaña carga y exigencia en ellas? La Universidad es, principalmente, una preparación para la vida laboral, y no creo que conseguir aparecer en 4+1 posiciones de 6 sobre fracaso académico ayude a nadie.
PD: no quiero alimentar suspicacias ni flames, lo del 4+1 es porque Telecomunicaciones e Informática a menudo son primas hermanas ;)

BlewSpace: geolocalización de blogs (¡pon tu blog en el mapa!)

2007-12-16T13:23:00.000Z

¿Es la geolocalización información interesante? ¿Alguna vez has querido geolocalizar un blog? BlewSpace es un nuevo mashup de Google Maps que pretende geolocalizar todos los blogs posibles. Quizá más que geolocalización se le podría considerar georegistro, pero al final lo que queda es un mapa con blogs, de forma que puedes situar el tuyo. Puedes registrar el tuyo para que la gente lo pueda localizar en un mapa (geolocalizar). También lo puedes categorizar e incluso hacerle ping (de forma que no se pueda registrar el blog de cualquier otro y decir que es basura).
Todavía está en beta (la moda 2.0 ;) ), y hay una interesante lista de peticiones que puedes incrementar.
Desde un punto de vista comercial creo que BlewSpace puede tener un potencial interesante, especialmente para la organización de reuniones de bloggers. Cuando BlewSpace active las consultas geoespaciales permitirá, por ejemplo, listar los blogs de tu ciudad.
La geolocalización hace las comunidades de la Web 2.0 más tangibles. Ya no son sólo grupos de avatares virtuales, sino gente real, de la cual alguna vive junto a tí.

Porqué Google son lo que son (los mejores)

2007-11-25T10:50:00.000Z

Otra nueva prueba de que cuando Google hace algo, lo hace lo mejor que se puede hacer: si al meter un nuevo evento en el Google Calendar lo haces tal que así: "7pm Baloncesto at Pisuerga every thursday" te crea un nuevo evento "Baloncesto" a la hora señalada, como lugar te mete "Pisuerga", y lo crea repetitivo semanal. ¿Simple? Sí. Pero dime cuántos años lleva funcionando el outlook y cuántos clicks necesitas para crear un nuevo evento así.

Para más información sobre esto, consultar su ayuda.

Chapó.

"Los puestos inmerecidos se preocupan por aparentar competencia y se rodean de personas mediocres"

2007-11-22T06:54:00.000Z

Hoy los blogs están sembrados... Ahora uno sobre la incompetencia en los jefes.

Las pruebas realizadas en la investigación concluyen que los jefes con poder legítimo se guían por la buena ejecución de la tarea, mientras que los de más dudoso mérito trabajan para mostrar la autoafirmación personal.
Los primeros se rodean de colaboradores competentes, y los segundos de colaboradores de dusosa competencia.

En cuanto pueda me leeré el informe, porque promete.
Hasta entonces, de nuevo me parafraseo:

Corolario: "en una empresa con jefes mediocres, sólo los mediocres ascienden, haciendo los procesos cada vez peores y aumentando la frustración de los competentes"

"La informática no da calidad de vida a las personas que viven de ella."

2007-11-22T06:33:00.000Z

He dudado hasta el último momento si poner esta anotación en mi blog personal o aquí, pero al final me ha tirado más lo profesional.

Hoy, en el repaso diario a mi HOME -cada mañana abro de golpe unas 15 páginas de periódicos, noticias, etc- me encuentro en barrapunto una reflexión sobre la (ausencia de) calidad de vida en informática que no por recurrente es menos importante.

Me parafraseo a mí mismo en un post que he puesto en esa misma página:
"Sobre el post principal, hay una novedad respecto a las reflexiones habituales: hablas de inestabilidad de tecnologías. Eso es cierto... hasta cierto punto. Primero, porque al final los conceptos son los mismos."

Yo no pido que todos los informáticos seamos vocacionales -esto debería ser una profesión, no una vocación-, pero sí que seamos profesionales. No tienes que irte a casa a seguir trabajando, ni acercarte a un ordenador si no quieres, pero cuando en el trabajo te enfrentes a un problema, hazlo de forma ordenada, paso a paso, exigiéndote a tí mismo calidad...

Frameworks J2EE

2007-11-18T23:14:00.000Z

En informática hay que reciclarse o morir. En parte, ese fue el espíritu de escribir este blog, que en parte me animaría a seguir investigando.

Para los que queráis poneros al día de cómo anda el mercado, acabo de encontrar una nueva noticia sobre comparativas entre frameworks. Hace tiempo la anterior comparativa publicada por el mismo autor me fue muy útil. En ella se mostraba JSF como claro dominador del mercado laboral.

En la nueva se habla de otros tantos frameworks, con datos sorprendentes sobre Flex (el framework para aplicaciones con Flash), supuestamente incluso algo más solicitado que JSF.

Luego, por otra parte, los más renombrados ahora son Seam (recién publicada la versión 2) y GWT (el framework de Google).

Si se me permite opinar, Seam tiene una pinta impresionante. Tan bueno como práctico. Para empezar, tiene una inmensa ventaja sobre todo lo demás: es un "todo en uno". La descarga son unas 100MB, y contiene todo lo que necesitas para trabajar con Hibernate (Core, Search, Annotations, Validator y Entity Manager), Seam, JSF, Ajax4JSF, RichFaces, Log4J y TestNG (esos son los que me conozco, alguno más me dejaré). Tiene vocación no sólo de integrar, sino de estar integrado. Aparte, el incipiente Red Hat Developer Studio lo soportará al 100%, con lo cual tenemos una pila completa (incluyendo el JBoss) para desarrollo, que era la única ventaja real de .NET sobre J2EE.

Los demás, pasarán, o sus ideas serán adoptadas por los demás (como está pasando con PHP y RoR, por ejemplo).

IMHO, por supuesto ;)

Hoja de ruta para un programador

2007-10-25T22:31:00.000+01:00

Como parte de reflexiones recientes estaba pensando en hacer un poco de autocrítica ¿qué debería leer una persona para aprender a programar correctamente? Está claro que para salir al mundo empresarial y poder pedir con lo que salimos de la facultad no tenemos ni para empezar, y no todas las empresas se pueden permitir grandes periodos de formación.
Como esto es un campo muy amplio, en este ejemplo hay una precondición: se parte de cero, y una postcondición: saber programar en un entorno J2EE con Hibernate+Spring+JSF.
Lo primero deberían ser las bases: comprender qué es un algoritmo, programación estructurada y estructuras de datos elementales. Yo hice un curso, y como bibliografía usábamos "Fundamentos de Programación", de Joyanes, y creo que sería perfectamente válido. Es importante coger las ideas fundamentales antes de atarse a un lenguaje de programación. No se puede empezar a programar si no eres capaz de especificar el algoritmo de hacer la lista de la compra o ir al cine a ver una película.
Una vez sabemos lo imprescindible, es hora de bajarse la última JDK, Eclipse, y, Thinking in Java en mano, programar todos los ejemplos. Por lo que sé, es el mejor libro de Java.
Una vez ya se sabe Java (bien, no como la mayoría se conforma), merece la pena ahondar un poco más: Advanced Java Programming.
En este punto ya se debería tener dominado el "Java standalone", "cliente", o como prefieras llamar a lo que no es J2EE.
En este punto ya se debe conocer la herramienta básica, así que conviene leer algo de más alto nivel: Core J2EE Patterns.
Antes de entrar en el mundo J2EE convendría unas nociones básicas de redes (¡me asombro que en el fondo mucha gente no acaba de comprender el modelo cliente-servidor de la web!) y algo de SQL. Para esto no tengo recomendaciones.
Ya es el momento de meterse en harina: a bajarse Hibernate, Spring, MyFaces... Nada de pasar por programación de servlets y JSPs pelonas, no vale para nada. Con leernos las introducciones para comprender qué es un servlet y cómo se genera la vista con JSPs, basta. Para aprender Hibernate el libro de referencia está muy bien, y cuando éste se queda corto, Hibernate in Action. La (¡extensa!) referencia de Spring debería ser suficiente. Y para JSF, el tutorial de Core Servlets con el que creo que hemos aprendido todos.

Aquí están las referencias. Ya sólo queda el trabajo ;)

Reflexión inter-desplegues sobre la falta de profesionales

2007-10-25T11:32:00.000+01:00

Entre despliegue y despliegue del servidor de aplicaciones (el lado negativo de las tecnologías J2EE es el frecuente reiniciar) me vienen a la mente comentarios de una reunión cercana.

Faltan profesionales, y los que hay están poco preparados. Cuesta horrores, especialmente si no puedes ofrecer un fajo de un espesor considerable, encontrar profesionales con experiencia. Somos pocos, y muchos se conforman con lo que se sabe de la facultad, que está muy alejado del Mundo Real ^tm.

Sres. empresarios, busquen a los buenos profesionales y págenles bien. Y si alguien es un programador impresionante, no le "ascendáis" a analista obligatoriamente. "Ascendedle" los honorarios y dádles responsabilidades, pero no consideréis la programación una tarea menor.

Sres. informáticos: leamos, cacharreemos, programemos... ¡mejoremos! Y, después, ¡pidamos!

NetBeans 6.0 Beta 1 + Tutorial

2007-09-19T06:53:00.000+01:00

Hoy se ha publicado la primera beta de NetBeans 6.0, que parece una actualización de la (impresionante) 5.x. Se han corregido algunas cosas y, sobre todo, se integra el desarrollo con Ruby.

De regalo, aquí está un breve tutorial de JPA + MySQL + NetBeans hecho por Luis Molina.

Red Hat Developer Studio

2007-08-14T21:57:00.000+01:00

He estado trabajando en un proyecto relativamente pequeño durante algunos meses (más de un año). Como lo comencé en la Época Antigua lo hice con Struts + Hibernate. Desde entonces la comunidad J2EE ha evolucionado mucho, y hay ciertas tecnologías que hacen que mi diseño anticuado parezca más viejo si cabe. Más específicamente, quiero Ajax para mis usuarios.

Quería migrarlo a una arquitectura JSF + RichFaces + Seam + Hibernate, pero quería esperar hasta que se publicase Red Hat Developer Studio, ya que soporta todas las tecnologías que quiero usar. Ese día ha llegado, y puedes descargar Red Hat Developer Studio Beta 1. En este post contaré su instalación y mis primeros minutos con él (en tiempo real). Ni es una reseña en profundidad (no puede serlo todavía) ni un estudio de Seam (por lo mismo) ni una guía J2EE para torpes. Espero que alguien lo encuentre interesante.

FYI, estoy en un portátil Centrino con 2GB y Gentoo.

Comienzo
1.- Descarga Red Hat Developer Studio Beta 1 for Linux: ¡~530MB! ¡Es grande!
2.- Arranca la instalación: java -jar rhdevstudio-linux-gtk-1.0.0.beta1.jar.
3.- Sigue las instrucciones. 3 minutos, sin nada a destacar. Crea un bonito icono en el escritorio.
4.- Picar en el bonito icono lanza un casque instantáneo (uno de los de eclipse). No sé exáctamente porqué, pero especificando la ruta java manualmente se soluciona: ./eclipse -vm /opt/sun-jdk-1.5.0.12/bin/java.
5.- Comienza con un diálogo de migración (desde JBoss Studio) que a mí no me vale para nada. Supongo que los usuarios de JBoss Studio lo valorarán.

PRIMERAS IMPRESIONES
Aparenta como lo haría Eclipse tras un lote de plugins. La perspectiva RHDS me da una primera alegría: una paleta RichFaces (todavía sin calendario, habrá que esperar). Un vistazo a "Manage Configuration" muestra que incluye, entre otros, los siguientes plugins:

Dali (JPA).
EMF (modelado).
JST (marcado como con problemas, espero que no sea grave).
WST.
Hibernate Tools.
JBoss stuff.
Shale tools.
Spring.

Hay también algunas perspectivas nuevas para mí que probablemente serán interesantes: jBPM PDL y JBoss AS. Profundizaré en ellas otro día.

PRIMER PROYECTO
Mi objetivo es comenzar un proyecto RichFaces + Seam + Hibernate (JPA) desde cero. Teóricamente es el mejor IDE para hacerlo, veamos si lo consigue. Desde la perspectiva RHDS:
1.- File --> New --> Seam Web Project.
2.- Añadir el facet Java Persistence al proyecto.
3.- Crear un database connection profile (el mío es MySQL 5.0).

Moviéndome un poco se hace lento y vuelve a cascar ("double free or corruption"). Aumentaré la memoria (eclipse.ini) y reiniciaré. Más tarde se hace obvio que lo que falla es el "Red Hat HTML Editor" (editor por defecto para JSPs). Probablemente se deba a un problema conocido en el FAQ. Nada urgente.

El proyecto tiene una interesante librería 'All JBoss Libraries' que contiene 50+ jars que esperemos que me permitan desarrollar sin preocuparme por jars por un rato. Algo similar ocurre con 'Web App Libraries', que incluye no sólo seam sino también otros must-have como facelets.

El proyecto tiene un error (cuadrado rojo). Se puede encontrar en la vista 'Problems': "no persistence.xml" file in project. Está mal, porque está en src/META-INF. ¡Despleguemos! Shift+Alt+X, R lo ejecutará en un servidor. Como no está configurado todavía, me pregunta en cuál. Elijo el JBoss 4.2 incluido y cruzo los dedos. Starting... ¡Casque! :-\ Sigh... Bueno... Algo falla con la base de datos: "Apparently wrong driver class specified for URL: class: com.mysql.jdbc.Driver".

Se soluciona metiendo el conector mysql en jboss-as/server/default/lib. Primera lección de JBoss aprendida. Tras ello, aparece la página de bienvenida.

Aparte del problema con el RH HTML Editor, RHDS parece prometedor. ¿Por fin el desarrollo en Java se encuentra con la integración de los Visual LoQueSea? Esperemos...

¡Ave, Buen Programador!

2007-08-03T19:45:00.000+01:00

Hace unos días estaba en una sala con unos cuantos programadores. Yo, como habitualmente, refunfuñaba sobre algo (ahora no recuerdo el qué), y como casi siempre volvió a salir de mi boca mi intención de mandar las nóminas a paseo y montar empresa. Y, aunque alguno se lo tomó a broma, conté que mi intención era, en cuanto un par de encargos lo permitiesen, coger sólo a los mejores programadores pagándoles el doble, o más, de lo que se paga habitualmente. Porque, como ya he dicho otras veces, yo también creo que la diferencia entre los buenos y el resto es espectacular. Acaba de caer en mis manos otro artículo que no tiene precio: 10 programadores por el precio de uno.
Si consiguiese reunir a cuatro o cinco de estos, pagándoles el doble todavía quedaría margen más que de sobra para hacer mucho dinero, a la vez que das un muy buen sueldo y un trabajo gratificante...

Soñar es gratis, supongo

Fechas

2007-07-30T06:40:00.000+01:00

Dilbert, real como la vida misma, como siempre.

(Escaso) interés de usuarios en Linux

2007-07-26T08:42:00.000+01:00

En el anterior post sobre interés en Linux ponía en duda su éxito en los últimos años, en términos de número de usuarios (especialmente por las expectativas creadas).

Tras una breve discusión en Barrapunto me puse a buscar cifras y, en cierta medida, se confirman mis sospechas. Aquí van algunas:

W3Schools: 2003, 2.6%; 2004: 3.1%; 2005: 3.3%; 2006: 3.3%; 2007: 3.4%. Pese a ser un sitio "técnico" el incremento en 3 años sólo fue un 0.7%, y este año incluso ha descendido.
MarketShare: 2004: 0.29%; 0.31%; 2006: 0.38%; 2007: 0.59%. Aquí la tendencia es alcista, pero en magnitudes irrisorias. Recoge los datos de muchas fuentes diferentes, así que parece que la realidad se acercará más a estor porcentajes que a los de W3Schools.

Mientras, los de Ubuntu se lo toman con filosofía, asignando a Mark Shuttleworth el bug de que Microsoft tiene la mayor parte de la cuota del mercado.

Me gustaría ofrecer más datos, pero esto es lo que he encontrado. Creo que Linux ha dado un gran salto cualitativo en los últimos 8 años, pero que esto apenas se ha reflejado en el número de usuarios. Linux ya es completo, cómodo y sencillo, pero los usuarios no necesitan el cambio. Ójala me equivoque, pero si va a conseguir hacerse un hueco en los hogares, no va a ser a corto ni medio plazo.

¿Se está perdiendo el interés en Linux?

2007-07-24T20:25:00.000+01:00

Me pasé a Linux hace ya alrededor de cuatro o cinco años. La principal razón era aprender, pero descubrí un sistema con el que no sólo no echaba de menos otros, sino que era más personalizable y mucho más estable (¡y determinista! =) ). Comencé suave, con Suse, y al cambiar de cacharro me pasé a Gentoo. Desde entonces he aprendido mucho con él (un francés me decía hace tiempo que "Linux le ayuda a comprender cómo funciona un ordenador"). No he necesitado nunca Windows (salvo para un programa para la Nintendo DS que ya puedo ejecutar con Wine), y con Gentoo seguiré hasta que me compre otro cacharro y seguramente me pase a Kubuntu (cada vez tengo menos tiempo para cacharrear).

Desde entonces ha llovido mucho, y creo que se ha perdido gran parte del interés en Linux. O, al menos, se ha estabilizado. En la siguiente gráfica de Google Trends se puede observar un alarmante descenso de las búsquedas (Windows en rojo, Linux en azul, Unix en amarillo):

Hace poco bromeaba en Barrapunto sobre que ya no hay flames sobre distribuciones (frecuentes cuando yo empezaba), y
creo que no es más que otro indicador de que las tendencias se han estabilizado, y eso es muy malo para Linux. Windows XP es un buen sistema operativo (o al menos infinítamente mejor de lo que Microsoft nos tenía acostumbrados en los hogares), y eso ha hecho que muchos se hayan conformado con él en vez de pasarse a Linux. Éste, a su vez, ha fallado en el escritorio (el contenido de la entrevista quizá es dicutible, pero parece obvio que las previsiones que había hace años sobre penetración de Linux en los hogares no se están cumpliendo): la base de usuarios no crece.

Y, entre las distribuciones, sólo una cosa clara: hay mucho interés en Ubuntu. Gentoo se mantiene constante, y la tendencia del resto es a la baja (Ubuntu en amarillo, Debian en rojo, Suse en azul oscuro, Red Hat en azul claro, y Gentoo en verde):

Para mí, la causa principal de que "usuarios técnicos" no migren es que Windows XP es bueno, como ya he dicho. Y la de que el resto no lo haga, la posibilidad de piratear Windows XP, la preinstalación de éste (legal o no), y la nula propaganda de alternativas.

Todavía albergo dos esperanzas: las compañías que, como Dell, dicen que preinstalan Linux (aunque no me acabo de creer que la gente no lo quite según reciba el ordenador), y, sobre todo, la apuesta gubernamental por el software libre. Los niños que ahora usan linux en la escuela en Andalucía o Extremadura, dentro de unos años lo verán como una opción más, en vez de algo para frikis.

WTF

2007-07-21T17:39:00.000+01:00

Por cierto, quien quiera reirse un poco que se suscriba a Worse Than Failure, una página en la que se van colgando pifias e ideas peregrinas™ a diario. Una de mis favoritas es "Securing Secure Security":

[OT] Premio Idea Peregrina™ #1: APPInformática

2007-07-21T17:11:00.000+01:00

Antecedentes a este post: cuando ví APP por primera vez, hace años, tenían una página web cómoda y bien implementada, pero desde entonces la han cambiado varias veces, y siempre a peor (IMHO, como todo lo que digo). El [OT] del título es porque este post es bastante off-topic a lo que viene siendo habitual, pero soy un bocazas que si no escribe su opinión, revienta.

Hoy he conseguido por primera vez hacer una foto aceptable con HDR, y dentro de poco me voy de viaje, así que he decidido comprar una tarjeta de memoria de al menos 2GB para poder hacer bastantes fotos en formato RAW. Tras visitar Ebay me meto en APP, que pese a que odio su web cada vez más suele tener buenos precios. Escaneo las categorías superiores y laterales buscando "Memorias" y no encuentro nada. Después me doy cuenta de que alguien ha preferido escribir "Otras memorias". Bueno, discutible, no me voy a quejar por eso...

Cuando por fin veo "Otras memorias" me lleva a 10 páginas de resultados, así que meto en el buscador de arriba 'cf', doy intro y ¡la búsqueda es instantánea! ¿Ajax? Imposible, ha sido ¡demasiado! rápido, y el monitor de red ni se ha inmutado... Sólo puede ser una cosa... ¡¡¡han metido todos los datos en Javascript!!! Al abrir el Firebug e ir al DOM ¡¡veo un array de 139 elementos con todas las memorias!!

¿Qué ocurre si buscas en la página principal? Vuelvo al inicio y veo que el buscador tiene dos opciones, buscar tiendas y buscar artículos. Por defecto está seleccionada la que es prácticamente inútil: buscar tiendas. ¿Por qué? Porque si "tiras del hilo" del código que tiene el radiobutton de buscar artículos ves que cuando lo seleccionas se añaden scripts javascript mediante DOM de scripts ¡¡¡¡y cargan toda la tienda, 2840 artículos, en el array 'database'!!!!

No contentos con eso se han limitado a poner en el cuadro de búsqueda "espere por favor", así que si estás hábil puedes buscar 'pentium' y que no encuentre nada... Esta gente ha visto que Internet está plagado de Ajax y una de dos, o lo han visto muy difícil de implementar, o han sido más listos que nadie... "¿Para qué esperar poco si puede no esperar nada? Enga, si total los ordenadores tienen memoria de sobra..."

Con esto voy a inaugurar una nueva sección, inspirada en "El empleado de la semana" de los genios de "Sé lo que hicísteis...":

1er Premio a la Idea Peregrina de la Semana™: www.appinformatica.com, por meter en un array Javascript toda su base de datos y descargarlo cuando el usuario indica que va a buscar artículos.

Orgullo programador

2007-07-12T16:46:00.000+01:00

Mientras que cruzando el atlántico se interesan en ser mejores programadores, en España la profesión de programador es una verguenza, a pesar de la escasez que ven todos.

Apenas hay programadores porque...

En la carrera cada vez entra menos gente, porque se paga mal y se vive peor.
La gente que está en este mercado intenta salir de ese puesto lo antes posible, ya que es la única forma de asomar las cejas por encima del mileurismo y/o subsubcontratación feroz.
Los jefes se piensan que un programador es como un albañil. Cito a Javier Pérez:

Las empresas aún no entienden que un programador no es un obrero, sino un ingeniero creativo que convierte ideas en tecnología. Y sin embargo los muy paletos nos culpan de la baja productividad que dicen adolece este bendito país. Ver para creer, los incompetentes negando competitividad.

Revindiquemos la importancia de la programación en nuestras empresas, nadie lo va a hacer por nosotros. La programación ni es ni será un trabajo mecánico, hagamos lo posible por ser los mejores, y exijamos como tal.

Primera aplicación con RichFaces

2007-07-03T17:47:00.000+01:00

Como parte del afán casi sadomasoquista que creo tenemos algunos informáticos vocacionales (los no vocacionales no sé qué hacen en este mundillo de bajos sueldos, malas condiciones laborales y nulo reconocimiento) voy a hacer una breve introducción a RichFaces, desde la instalación del IDE hasta el punto de tener una aplicación mínima funcionando. El objetivo no es hacer un tutorial, ni un howto, ni una guía paso a paso (si estás leyendo esto eres informático o como mínimo curioso, no creo que necesites que te digan "pulsa siguiente"). Aún así, si siguiéndola has tenido problemas, soy todo orejas.

1.- Descargamos la última versión de NetBeans 6 M10.
2.- Descargamos los últimos builds de RichFaces y de Ajax4JSF, incluyendo las fuentes (para el javadoc y depuración). En breve se fusionan en un único proyecto.

**Las últimas versiones, inestables, porque estoy en casa. No hagan esto en el trabajo ;)

3.- Mientras se descargan las 180MB anteriores echamos un ojo al manual de desarrollador de RichFaces y de Ajax4JSF.

4.- Lanzamos el instalador. Durante mi instalación, aparte de los pasos obvios, he hecho...

Configurar que también me instale el Tomcat 6, ya que estamos.
Cambiar los passwords por defecto y los puertos para intentar olvidarlos lo más tarde posible.

5.- Abrimos netbeans y creamos un nuevo proyecto Web sobre el SJSAS 9 recién instalado. Activamos JavaServer Faces.
6.- Pulsamos F6 (hay que ir aprendiendo los atajos de NetBeans ;) ) para arrancar el servidor, desplegar y abrir un navegador. Debería mostrar en un h1 el texto JavaServer Faces. Prometo que he llegado hasta aquí del tirón :)

7.- Descomprimimos la descarga de RichFaces, que contiene tanto Ajax4JSF como RichFaces.
8.- Creamos una librería con estos jars y la añadimos al proyecto: propiedades del proyecto --> librerías --> añadir --> gestionar --> nueva librería. Añadimos tanto los jars binarios como las fuentes.
9.- Aplicamos los cambios indicados en la configuración para una aplicación con RichFaces: añadimos la configuración al web.xml y el taglib de richfaces.
10.- Reiniciamos el servidor de aplicaciones. Mientras reinicia podemos ir aprovechando para saludar en el foro de RichFaces. Lo vamos a usar mucho y los desarrolladores del proyecto han demostrado conmigo una paciencia infinita :) Nunca había visto un tiempo de respuesta tan bajo en un proyecto OpenSource.

** Primer problema de usar versiones inestables de todo. El servidor se ha parado, pero netbeans no se da por enterado. Se ha solucionado al dar F5 para volver a lanzar **

11.- Primer error (no está mal haber llegado hasta aquí): NoClassDefFound por no haber metido Commons Logging, del que depende. Hay que añadir las siguientes librerías (todas mediante el gestor de librerías del proyecto de NetBeans):

commons-logging (incluída con NetBeans)
commons-digester (descargar)
commons-collections (descargar)
commons-beanutils (descargar)

12.- Reiniciamos el servidor, y ¡voila!

No es que sea algo espectacular, pero es un comienzo.

PD: si a alguien le sobra un monitor de 19", que me avise, que el mío se queda pequeño para todos los paneles de netbeans :)

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

2007-06-28T16:37:00.000+01:00

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 ;)

Google Desktop para GNU/Linux

2007-06-28T16:22:00.000+01:00

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 ;)

Programar sin el ratón (Hay que)

2007-06-20T19:47:00.000+01:00

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...

Versiones (reflexiones)

2007-06-20T19:34:00.001+01:00

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...

Las promesas de JBoss Seam

2007-06-16T09:41:00.000+01:00

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...

Project Server 2007

2007-06-12T18:20:00.000+01:00

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...

El talento y el desarrollo (obviedades)

2007-06-07T16:20:00.000+01:00

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:

"Los mejores programadores pueden ser 20 veces más productivos que los medios... el 50% de los programadores se consideran a si mismos que están en la categoría de los mejores, pero en realidad sólo está el 1%" --Lawrence Bernstein en Trustworthy Systems Throrgh Quantitative Software Engineering

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.

Elegir un IDE para Java

2007-06-07T15:43:00.000+01:00

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:

Eclipse:

MyEclipse:
Exadel Studio: antes propietario, va a ser liberado como Red Hat Developer Studio.

Netbeans:
JDeveloper:
IntelliJ IDEA:

La (pobre) pesca de esta primavera devuelve los siguientes resultados (¡agradeceré toda aportación posible!):

Premios 2007 de los lectores de Java Magazin (en alemán): Eclipse (63%); NetBeans (9%); IntelliJ IDEA (8%).
Comparativa de alguien que eligió NetBeans (del 2007, y empezó con vim, así que no puede ser mala persona ;) ).
Eclipse vd. Netbeans vs. IntelliJ IDEA: más democrático, elige NetBeans para desarrollo swing e IntelliJ (seguido muy de cerca por MyEclipse) para Struts/JSP y JSF.
Netbeans 6 vs Eclipse 3.3
MUY INTERESANTE: encuesta anual de BZ sobre IDEs: Eclipse 70%, NetBeans 23%, JDeveloper 19%, IBM RAD 20% (la pregunta no era exclusiva, suman más de 100 ;) ). Ya que estamos, servidores de aplicaciones: WebSphere 37%, JBoss 32%, BEA WebLogic 24%.

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.

Facelets

2007-06-05T20:56:00.000+01:00

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).

Los estándares no valen para nada

2007-06-04T21:53:00.000+01:00

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...

Google Code Search

2007-06-04T21:06:00.000+01:00

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

Google Gears: Unplugged Web 2.0

2007-05-31T15:58:00.000+01:00

Hace unos días escribía sobre aplicaciones web offline sin saber que Google sacaba ya su solución: Google Gears. Los estándares son buenos, pero ¿quién quiere esperar a un estándar cuando tus ingenieros son los mejores?

Lo acabo de instalar. Al entrar en Google Reader, la primera aplicación que lo soporta, aparece el siguiente mensaje:

Marco que lo recuerde y le permito acceso. Al entrar en la aplicación, en el menú de opciones aparece un nuevo icono. El tooltip reza lo siguiente: "Currently online. Click to go offline". Lo pulso, como no puede ser de otra forma, y aparece una barra de progreso con el estado de la descarga de noticias:
Lo quedo en modo offline y el monitor de red ni se inmuta a partir de entonces: puedo leer noticias "desenchufado".

¿Y si ahora me quedo sin conexión? /etc/init.d/net.eth0 stop... Ok. Puedo seguir viendo noticias, están en mi caché local. En la ayuda de Google Reader indican que debería poder cerrar la ventana y volver, sin conexión, y debería funcionar. Lo pruebo y efectivamente funciona (parece que hay un pequeño problema y el contenido no se carga hasta que pulso algún enlace en la página, pero bueno, es una beta sobre otra ;) ).

Nada que no pudiese hacer antes con alguno de los miles de lectores RSS que ya hay, pero no es lo mismo. Las aplicaciones de sincronización han muerto. En breve todas las aplicaciones serán Web y nuestros datos estarán en un único sitio, cacheados en varios.

Google lo ha vuelto a hacer, justo a tiempo para competir con ~~Silverlight de Microsoft~~ Apollo, de Adobe. ~~Pero claro, sólo uno funciona en "el otro" sistema operativo y "el otro" navegador ;)~~

Corrección: Silverlight no incorpora nada para trabajo offline.

Entierra con el hacha las pantallas de edición

2007-05-29T20:27:00.000+01:00

Cuando conocí Flickr, me gustó. Pero cuando me convertí en usuario me enamoró por lo terriblemente bien hecho que está el interfaz, muy especialmente un detalle: si algo en la pantalla es editable por mí, lo puedo editar directamente. Por ejemplo, si doy de alta una foto, cuando estoy en su pantalla de detalle, si pulso en el título, el texto se convierte -elegantemente- en un campo de entrada, y puedo editar el valor, que se almacena vía Ajax (como el componente inline de Dojo).

Esa comodidad viene de romper con un hábito habitual: separar las pantallas de ver y de editar. ¿Para qué? Yo, usuario de la aplicación, no quiero tener que pasar a "modo edición" cada vez que quiera cambiar un dato. Si estoy viendo algo que puedo editar, debo poderlo editar, sin indicarle a la aplicación "¡oye, que voy a editar!". El componente de edición inline a mí me encanta pero para muchos usuarios puede ser confuso, por lo que, en una aplicación web, este principio se traduce a que si un dato no es editable debe aparecer como texto (¡no en un campo deshabilitado!), y si es editable, en un campo.

Esto en muchos entornos se traduce en jsps llenas de ifs, o, con suerte, de c:ifs, lo cual ni es productivo, ni mantenible, ni legible. Sin embargo, si puedes utilizar JSF y Tomahawk, no debes dejar pasar el atributo displayValueOnly de (casi) todos los campos de entrada. Permite, mediante una expresión JSF, decidir si algo se muestra como texto o como campo. Mejor, imposible. Y, para gestionar también el permiso de visibilidad sobre una propiedad, tienes el rendered. Con estos dos atributos manejas los tres permisos elementales (visibilidad, lectura y escritura) de la forma mínima.

Se acabó tener que programar varias pantallas en función de permisos y modos. Con una única pantalla podemos mostrar sólo lo que un usuario pueda ver (¡a nivel de propiedad!) y editar sólo lo que pueda editar.

Java QuickTip #0: comparaciones de igualdad

2007-05-27T13:48:00.000+01:00

Cuando hagas comparaciones de igualdad de objetos, en vez de hacer

miCadena != null && miCadena.equals("hola")

haz

"hola".equals(miCadena)

Funciona igual y nunca te olvidarás de hacer la comprobación de no nulidad.

Técnicas ágiles

2007-05-27T10:37:00.000+01:00

Las metodologías ágiles fracasarán, como todas las demás metodologías, porque en informática lo importante no son los procesos, sino el talento. Además, porque aprovecharlas probablemente significa olvidarse de CMMIs, ISOs y demás siglas que les gusta a los tipos encorbatados que impiden que las cosas se hagan como se debe.

Sin embargo, sus técnicas están aquí para quedarse:

Testing: hacer pruebas es poco costoso y muy beneficioso. Permite desarrollar más ágilmente, sin intervención de pesados servidores de aplicaciones. Detecta errores en cambios (¿cuántas veces las cosas dejan de funcionar y es el usuario el que lo detecta?). En Navegápolis listan herramientas de pruebas, a las que yo añado las siguientes:

JMeter: pruebas de carga y funcionales.
BadBoy: un Internet Explorer que permite "grabar macros" para después lanzarlas. Permite probar Javascript, y su proxy funciona incluso usando https y certificados de cliente (ya que se ejecuta "por encima del navegador", en vez de "por debajo" como el JMeter).
Unitils: un recubrimiento de JUnit y otras cuantas que como mínimo te facilita la vida hasta que todos (JUnit, Spring...) se pongan de acuerdo para funcionar de verdad juntos.

Integración Contínua: mantenme informado de cómo va el código de nuestro proyecto (¿compila al menos? ¿pasa las pruebas? ¿cumple las métricas? ¡avísame al messenger si hay problemas!)

Continuum o CruiseControl son las dos herramientas OS más comunes.

Olvidarse de tantos diagramas UML, documentos de viabilidad, planificación, requisitos, análisis, diseño, presentaciones powepoint y demás basura que no sirve para casi nada, y "símplemente hacerlo (6:00)".

PD: el artículo citado antes enlaza a su vez con otro sobre procesos de obligada lectura, y saca de él una cita que no puedo menos que plagiar también:

Las pautas que en los entornos industriales logran eficiencia, en el software producen mediocridad.
Gestionar empresas del conocimiento con teoría de management industrial genera productos mediocres y técnicos desmotivados.

La Web: la piedra filosofal de la informática

2007-05-26T16:39:00.000+01:00

La web pretende convertirse en los próximos años en la plataforma (casi) perfecta. Si hiciésemos una lista de características de una aplicación ideal podríamos indicar, por ejemplo, que no tuviese instalación, que pudiese acceder a ella desde cualquier sitio, que no necesitase conexión a Internet para funcionar, pero que la aprovechase si la tuviese, que se actualizase automáticamente (¡y gratis!), que facilitase el trabajo compartido...

La teoría es que esto se podría conseguir casi con cualquier lenguaje, pero sólo la Web ha conseguido meterse (hasta el tuétano) en nuestra vida. Así que, lo que a priori es una basura de plataforma (estándares ineficaces, implementaciones deficientes, problemas de seguridad, frameworks complejos, pocas herramientas útiles...) va camino de convertirse en los próximos años en la piedra filosofal. Google Docs viene anticipando desde hace meses la muerte de los paquetes de ofimática gracias a Ajax, pero la siguiente generación de navegadores se pretende convertir en una plataforma de ejecución mediante aplicaciones offline. La idea es tan "simple" como que los recursos se almacenen en una caché local con el rel="offline-resource".

Hasta ahora, por ejemplo, teníamos el ~~Word~~ OpenOffice, programado en C++ y compilado a código máquina, ejecutándose con el procesador interpretando este código. Periódicamente ~~pirateamos~~ emergemos la versión nueva, cuando vamos a otro ordenador, lo instalamos también...
En breve tendremos una nueva versión de Google Docs, que se ejecutará sobre el intérprete JavaScript de Firefox, que si estamos conectados a Internet ejecutará la ultimísima versión, y si no, la de la última vez que entramos. Nada de instalaciones, nada de actualizaciones... Sí, es más lento interpretar JavaScript que ejecutar código máquina, pero ¿para qué queremos si no estos fantásticos procesadores de n núcleos que nos venden?

Por si alguien no le da importancia, tanto Microsoft con Apollo como Adobe con Flex ya se han posicionado para dominar un mercado difícil de dominar. Incluso Dojo tiene un paquete para aplicaciones offline.

Pestañas

2007-05-25T16:01:00.000+01:00

En términos de usabilidad, las pestañas son seguramente mi componente favorito. Aunque a Jacob Nielsen no le guste el (supuesto) abuso que se hace de ellas, son un modo fantástico de organizar la información. Por ejemplo, ahora mismo mi pantalla tiene dos grupos de pestañas: las de Firefox, que organizan las páginas de consulta para escribir este artículo, y las que Blogger utiliza para organizar la edición del blog. A Jakob Nielsen posiblemente estas segundas no le gustarían, ya que son de navegación, no para mostrar diferentes vistas de una misma cosa...

En el libro Don't Make Me Think les dedican unas siete páginas, que os paso a resumir:

Es una de las pocas metáforas que funcionan plagiadas directamente de El Mundo Real™: de un plumazo muestran la estructura de un elemento, organizan su información y permiten acceder de forma rápida a apartados específicos.

Son obvias, fáciles de usar y fáciles de comprender (en el fondo esto es repetir tres veces lo mismo).

Amazon fue uno de los primeros sitios en usarlas. En mi opinión, la parte del libro en el que hace un estudio sobre la evolución de las pestañas de Amazon es de obligada lectura para todo diseñador Web. No vayáis ahora a Amazon a ver cómo son, porque prácticamente las han suprimido, ya que se toparon con su principal problema, que es que...

... escalan mal: más de siete pestañas casi siempre son demasiadas. Tanto por espacio físico como por el modelo mental que el usuario hace de ellas al usarlas.

En términos (web) prácticos, mi implementación favorita es la que tiene el portal hispano de Ubuntu, basada en listas de elementos, enlaces y CSS. La técnica queda descrita en este ejemplo de pestañas. Permiten tener varias líneas de texto, si desaparece el estilo queda html comprensible (buena accesibilidad, por tanto), vistosas (al usar imágenes de fondo, en vez de tablas), etc.

Sin embargo, al pensar en nuestra ¿querida? generación de páginas en Java y ahora que estoy metido hasta el cuello en JSF y Ajax, me abordaba una duda: ¿navegación tradicional (cliente-servidor puro), navegación cliente (sólo Javascript), o Ajax? La primera es lenta para el usuario, pero de fácil implementación. La segunda es la más rápida una vez cargada, pero la más lenta de carga, al generar todas. La tercera, un buen término medio, pero de compleja implementación... hasta que conocí las pestañas de RichFaces. Una vez superas ciertos problemas técnicos, se convierten en un perfecto 3 en 1. Con cambiar un parámetro cambias entre los tres modelos anteriores. La única pega, que son tablas :\ En cuanto tenga tiempo espero hacer un componente semejante, basado en Ajax4JSF como RichFaces, que implemente las pestañas elegantes de Ubuntu.

PD: me gustan tanto que las he metido en el blog (en formato cliente puro). Están arriba, sobre la imagen de cabecera, e iré recopilando en ellas las referencias, estándares y blogs que hacen del mundo del desarrollo de software un mundo un poco más llevadero.

JSF (Una historia de amor y odio sin final todavía)

2007-05-23T15:30:00.000+01:00

Conocí a JSF en medio de una relación. Llevaba un par de años con Struts. Al principio me había parecido (Struts) engorroso y pesado (venía de un largo affair con PHP), pero una vez conocí a sus parientes Validator y Tiles, me ganó. Me acabó convenciendo la potencia de utilizar ficheros de configuración para casi todo, y su orientación a las acciones me parecía una forma natural de programar en MVC.

En un viaje a la capital me presentaron a JSF, y mi impresión no pudo ser más tibia. Tenía la sensación de estar haciendo lo mismo, pero de otra manera, con ficheros de configuración que no me aportaban nada, y con etiquetas menos potentes que antes. Además, no vino solo, sino que iba acompañado de Spring e IBatis, haciendo que romper el hielo fuese todavía más difícil. ¿Qué me aportaba pensar en componentes en vez de en acciones?

De repente, un tercero se cruzó en mi camino y lo ví claro: Ajax. Todo cobraba sentido. Un campo de texto nunca más sería una caja vacía hasta que alguien pulsa el botón. Ahora, un campo de texto despliega sugerencias, se conecta al servidor para validarse de forma asíncrona, activa y desactiva partes de la página... Y si quieres programar esto de forma productiva, JSF es la elección.

Hasta aquí, la bonita historia de amor que se ve. Lo malo es cuando lees entre líneas. JSF es un estándar limitadísimo en términos de componentes (y no sólo lo digo yo). Es tan solo un framework sobre el que montar algo más interesante. Nació en el 2004 como la oferta de Sun ante el despropósito de J2EE al programar aplicaciones web, pero no ha sido hasta masificación de Ajax cuando se ha empezado a invertir en él.

Las implementaciones (MyFaces, Sun RI, Facelets...), frameworks (Ajax4JSF, ICEFaces, Tobago...) y librerías de componentes (RichFaces, Tomahawk, jMaki...) prometen mucho, pero en la práctica hacerlas funcionar es desesperante. Mala documentación, incompatibilidades, tener que recurrir a betas, sandboxes, nightshots...

Aún así, creo que ahora mismo la mejor opción para elegir un MVC si quieres Ajax es JSF. Concretamente, (MyFaces + Tomahawk (imprescindibles)) + (Ajax4JSF + RichFaces (potentes)). Los dos primeros proporcionan un conjunto base razonablemente estable y completo, y los dos segundos, toda la potencia de Ajax (aunque mezclar ciertos componentes con otras librerías es poco menos que imposible).

Se agradecerán sugerencias...

P.D.: MyFaces se mueve mucho. En el wiki hay un buen lote de artículos de JSF, MyFaces e incluso de integración con otras librerías

Actualización: leo en un blog un curioso gráfico del número de librerías Ajax existentes para diferentes tecnologías. La gráfica corrobora mi teoría de que, a pesar del caos de librerías, JSF es la opción para implementar aplicaciones Ajax.

Actualización 2: esa gráfica sale de una interesante comparativa de frameworks J2EE, muy actualizada

Nuevo borrador de WCAG 2.0

2007-05-18T19:20:00.000+01:00

El Web Content Accessibility Guidelines Working Group (WCAG WG) es la máxima autoridad de Internet en términos de accesibilidad. Suyo es el único estándar de usabilidad reconocido internacionalmente (y legalmente), el WCAG 1.0. El problema es que ese estándar es de 1999, y está totalmente desfasado. Está orientado únicamente a accesibilidad en contenido web, pero, ¿qué ocurre con las aplicaciones web?

Las aplicaciones web no son comparables a las páginas a las que fue destinado aquél estándar hace ya 8 años. Las aplicaciones web no son (principalmente) un medio de distribución de contenido, sino que son un sustituto de las aplicaciones de escritorio, no se puede aplicar las mismas reglas. Especialmente ahora que todos nos volcamos en Ajax para hacerlas más usables, rápidas y cómodas.

Hoy se ha publicado un nuevo borrador del siguiente estándar, WCAG 2.0, llamado a sustituir al primero y permitir el uso de estas nuevas tecnologías. Sólo queda que tarde o temprano se convierta en estándar estable (lo llevan prometiendo desde el 2005), y al fin se podrá cumplir la ley, proporcionando aplicaciones accesibles, sin tener que renunciar a los últimos avances en desarrollo web.

Esto hará, además, que se sustituyan las aplicaciones de escritorio (las cuales nunca fueron objeto de legislación sobre accesibilidad) por otras, basadas en tecnologías web, que acercarán la informática a usuarios con discapacidades.

Metodologías ágiles

2007-05-17T21:08:00.000+01:00

Algo va mal cuando nadie quiere utilizar metodologías pesadas como RUP o METRICA. Algo va muy mal cuando, siguiendo esas tecnologías, se hace lo que buenamente se puede en el tiempo disponible y después los diseños no se utilizan en la construcción, ya sea por incapacidad del autor o del programador (o de ambos).

Desde hace años existen las metodologías ágiles de desarrollo de software. Algún profesor de Ingeniería del Software nombraba XP (eXtreme Programming) con la boca pequeña, como aquella cosa que hacen los que no saben nada más que programar. Sin embargo, cuando lees ingenieros de Microsoft que a todas horas hablan de Scrum, o incluso de Cuales, algo notas que está cambiando.

Hoy, para echar más leña al fuego, aparece la noticia de que Oracle compra Agile Software Corp., una empresa que desarrolla herramientas de soporte para procesos ágiles.

Cuando el río suena...

DRY: Breve guía para mantenerse seco

2007-05-11T19:02:00.000+01:00

Hace años un profesor de Bachiller nos contaba que hay unos pocos principios que explican la gran mayoría de los fenómenos de la naturaleza. La ósmosis, el principio de conservación de la energía y otros pocos son capaces de modelar una gran parte de lo que vemos.

Pienso que en informática pasa lo mismo. Pese a los cientos de lenguajes de programación, librerías y plataformas que existen, los fundamentos que hacen de ellos una buena herramienta son muy parecidos. Entre ellos el que más importante me parece es el "principio DRY": Don't Repeat Yourself. Repetirse supone trabajar más (un buen programador debe ser vago), duplicar los errores, reducir la mantenibilidad del código, hacer más costosos los cambios... De ahí la gran frase de "Cada vez que cortapegas, Dios mata un gatito".

Mi entorno de trabajo desde hace unos años es J2EE, y para mantenerme seco utilizo estas herramientas:

Hibernate: minimizar el código de acceso a datos.
Hibernate Validator: aprovechar la especificación de persistencia para comprobar la validez de los datos recogidos en formularios, y mostrar mensajes adecuados. Y si no usas Hibernate, al menos usar Commons Validator.

"Trocear las páginas", ya sea con Tiles (imprescindible si usas Struts) o componentes (la mejor forma de reutilización en JSF).

Uso intensivo de CSS para la presentación. Nada de aprovechar CSS para mejorar la apariencia, sino componer las páginas independientemente de la presentación, delegando al 99% en los estilos (el 1% restante es para apaños para el IE).

Ideas + Ingeniería del Software

2007-05-06T20:03:00.000+01:00


/**
 * Blog sobre desarrollo de software.
 *
 * @author Juan Ignacio Sánchez Lara
 * @version v0.00
 * @since 070509
 * @see http://juanignaciosl.blogspot.com/
 */
public class I2S extends Blog implements DesarrolloDeSoftware, J2EE {

    //TODO: comentario ocurrente para el primer post de un blog sobre desarrollo.

    //FIXME: faltan las librerías de chistes graciosos.

}