WCAG 2.0 (finalmente)

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.

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



Accesibilidad y aplicaciones web

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.

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



Los roles en el desarrollo de software

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

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



Reseña: Facts and Fallacies of Software Engineering

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

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



Manifestación Informática 19N


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.

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



Problemas a la hora de la huelga

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

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



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

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

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



Eclipse: el núcleo del entorno de desarrollo

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

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



Organizando un entorno de desarrollo libre

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

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



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

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.

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



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

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

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



12 segundos de oscuridad

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

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



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

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?

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



Antipatrón: pensar en cambios

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.

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



Las mismas discusiones durante 33 años

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

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



El empleo en la informática

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.

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



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

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

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



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

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. 

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



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

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.

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