Archive for June, 2006

Lo que salió del RailsDay06

Si hace unos días contaba que había tomado parte del Rails Day 06, hoy puedo contar que Aitor ha puesto online el resultado. Obviamente no está terminado ni de lejos, pero teniendo en cuenta las circunstancias no está mal.


Más detalles en el post de Aitor al respecto.

Diseño web

La verdad es que yo sé bastante poco de diseño, de HTML, de CSS/CSS2 y demás historias relacionadas con lo que, tristemente, al final es lo importante: el aspecto visual. Sé poco de como hacerlo, pero lo suficiente sobre lo que está bien y esta mal, llevo 6+ años haciendo páginas web. He ayudado a varias personas a reciclarse en este sentido, y todos ellos están muy contentos, aunque yo siga sin saber si en un CSS una clase o un id se pone con “.” o con “#”.


También quizás porque el mundo de los informáticos con interés en el trabajo nos obliga a estar aprendiendo constantemente, pero hay días, en los que ves algunas cosas que te dan ganas de acordarte de los (obviamente para nada culpables) familiares de algún diseñador.

En fin.

Rails Day 2006

Ayer participé en el Rails Day 2006 junto con Aitor. Creo que éramos los únicos españoles entre los 180+ equipos. Unos portugueses, un par de alemanes, algún canadiense, australiano…. y mucho americano. Nosotros sólo usamos 8 de las 24 horas disponibles, por lo que tampoco espero que ganemos nada, pero bueno, pasamos un muy buen rato, eso sí :-D.


Nuestra aplicación… la veréis online pronto, pero la experiencia ha sido mi primer escarceo serio con el famoso Ruby On Rails.

Ya que Ibon está preocupado, un pequeño resumen sobre este contacto con RoR:


  • El fácil: puede ser que sea más rápido programar en RoR. El mero hecho de ser más pequeño y convencional ya es un plus (en java hay demasiadas posibilidades demasiadas veces), y el que la mayoría de la gente que llega a RoR provenga de Java (u otras plataformas) también hace que no se parta de cero. El problema puede venir (si viniera!) para una aplicación de uso intensivo, a veces los logs asustan.

  • El hecho: hacer cualquier aplicación de cara al gran público con un acabado final profesional cuesta se haga como se haga ;-).

  • El truco: si estas con alguien que ya sabe se aprende más fácil y rápido ;-). No estoy seguro de que Aitor no este tan contento con mis interrupciones, pero bueno.

  • El bonus: aprender algo nuevo. RoR no es la solución a los problemas del mundo (no hoy, no ahora), pero siempre es divertido hacer algo nuevo.



Se usará RoR en Linking?. ¿Por qué no?, hay sitio para todo.


PS: Estuve buscando un Rails for Java Developers, pero no lo encontré, algún día quizás lo escriba.

UPDATED 19/06/06, 11:25: Aitor da su opinión y muestra nuestro trabajo.

Debug en JSF

Uno de los mayores problemas que nos podemos encontrar al trabajar con JSF es lo oscuro que puede llegar a ser cuando ocurre un error. Si tenemos suerte y es un fallo de nuestro modelo, nos sacará la traza en la pantalla, si no tenemos tanta, nos lo sacará en los logs del servidor. Pero y si el problema no es de nuestro código (ejem, siempre es de nuestro código ;-) ) y es un problema ocurrido (seguramente con razón ;-) ) en una de las fases del ciclo de vida de una petición JSF (esto lo dejo para otro día si hay peticiones). Simplemente le damos a enviar y volvemos a la misma página. ¿Cómo podemos saber que está pasando?.


La parte fácil, pero que muchas veces se nos olvida es usar los tags message y messages. El primero para un componente concreto, el segundo para todos los errores de la página. Este segundo será de más utilidad si usamos algunos de sus atributos, como por ejemplo showSummary o showDetail. Es un primer paso. Pero, ¿no podemos conseguir más información?. Si, podemos usar Faces Trace.


FacesTrace es una herramienta desarrollada por Cagatay Civici y Yigit Darcin que nos permitirá en todo momento saber que pasa en nuestra aplicación Java Server Faces, mostrando en la misma página toda la información sobre el estado de la aplicación.


Free Image Hosting at www.ImageShack.us



La instalación es muy sencilla (es una taglib, ojo a la doc de la web a día de hoy, tiene mal el prefix de la misma), pero su utilidad es grande. Recomendable.

Por si las moscas (más diálogos en shale)

Hace unas fechas ya, hablé los diálogos en Shale. Dije en su momento que la idea me había gustado bastante y así sigue siendo, peeeeeeero (todo tiene que tener un pero :-( ) tienen un pequeñito problema que esta pendiente de resolver.


Y el caso es que como bien se describe en el JIRA del proyecto, es fácil entrar a un diálogo pero no tanto salir de él (o tener varios a la vez funcionando), y parece que van a tardar en arreglarlo.

Una posible solución por si alguno se anima a emplear estos diálogos (de eso va este post!) es la de usar unos mapping que te generen salidas del diálogo para, por ejemplo, las entradas de un menú. Aunque esto tiene varias limitaciones, entre ellas:


  • Es un coñazo, poco intuitivo.

  • Tengo que mantener esos mapping en varios sitios: la configuración de mi aplicación y la configuración de cada diálogo.

  • Repetir lo que sea es tu código es malo, malo, malo.

  • Sólo es aceptable para menús pequeños, de pocas entradas, otra cosa es inmantenible (porque automatizar este parche…).



En la página de Shale ya comentan la estabilidad de cada uno de estos módulos. En concreto en lo referente a los diálogos, tenemos:


  • org.apache.shale.dialog

  • Developing

  • Expect further development to support multiple active dialogs in the same page.


Así que no se puede quejar uno, y como diría aquel, eh!, es software libre, hazlo tu mismo ;-).



Close
E-mail It