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

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

Posted by Juan Ignacio Sánchez Lara 6:44 Enlaces a esta entrada  



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

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

Posted by Juan Ignacio Sánchez Lara 13:23 Enlaces a esta entrada  



Porqué Google son lo que son (los mejores)

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

Posted by Juan Ignacio Sánchez Lara 10:50 Enlaces a esta entrada  



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

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"

Posted by Juan Ignacio Sánchez Lara 6:54 Enlaces a esta entrada  



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

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

Posted by Juan Ignacio Sánchez Lara 6:33 Enlaces a esta entrada  



Frameworks J2EE

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

Posted by Juan Ignacio Sánchez Lara 23:14 Enlaces a esta entrada  



Hoja de ruta para un programador

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

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



Reflexión inter-desplegues sobre la falta de profesionales

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!

Posted by Juan Ignacio Sánchez Lara 11:32 Enlaces a esta entrada  



NetBeans 6.0 Beta 1 + Tutorial

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.

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



Red Hat Developer Studio

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

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



¡Ave, Buen Programador!

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

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



Fechas

Dilbert, real como la vida misma, como siempre.

Posted by Juan Ignacio Sánchez Lara 6:40 Enlaces a esta entrada  



(Escaso) interés de usuarios en Linux

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.

Posted by Juan Ignacio Sánchez Lara 8:42 Enlaces a esta entrada  



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

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.

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



WTF

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":

Posted by Juan Ignacio Sánchez Lara 17:39 Enlaces a esta entrada  



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

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.

Posted by Juan Ignacio Sánchez Lara 17:11 Enlaces a esta entrada  



Orgullo programador

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.

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



Primera aplicación con RichFaces

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

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



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

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

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

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

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



Google Desktop para GNU/Linux

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

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

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

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



Programar sin el ratón (Hay que)

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

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

Mis sugerencias:

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

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



Versiones (reflexiones)

En los últimos días...

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

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



Las promesas de JBoss Seam

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

Novedades principales de JBoss Seam:

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

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



Project Server 2007

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

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

Pros:

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

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

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



El talento y el desarrollo (obviedades)

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

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

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

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

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

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

  • Errores de selección de personal:

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

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

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



Elegir un IDE para Java

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

Los principales contendientes en estos momentos son:


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

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

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

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

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



Facelets

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

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

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



Los estándares no valen para nada

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

Unas cuantas muestras:

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

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

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

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



Google Code Search

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

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

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

Actualización: enlace al plugin corregido

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



Google Gears: Unplugged Web 2.0

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.

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



Entierra con el hacha las pantallas de edición

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.

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



Java QuickTip #0: comparaciones de igualdad

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.

Posted by Juan Ignacio Sánchez Lara 13:48 Enlaces a esta entrada  



Técnicas ágiles

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

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



La Web: la piedra filosofal de la informática

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.

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



Pestañas

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.

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



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

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

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



Nuevo borrador de WCAG 2.0

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.

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



Metodologías ágiles

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

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



DRY: Breve guía para mantenerse seco

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

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



Ideas + Ingeniería del Software


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

}

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