Javi Sanromán

El proyecto en el que trabajo actualmente es mi primera experiencia mas o menos seria con el desarrollo orientado a tests. Al principio los escribía después de implementar la funcionalidad requerida, pero por recomendación de un compañero pasé a escribirlos antes (TDD). Escribes el test que falla porque todavía no tienes implementada la funcionalidad que lo hace pasar, implementas la funcionalidad para que pase el test, y le das las vueltas que necesites a tu código (para hacerlo mas legible o eficiente) si el test pasa tu código es válido.

Cuesta iniciarse en esta forma de desarrollo, cuesta escribir buenos tests, cuesta mantenerlos, pero como se suele decir es una inversión con retorno y me estoy convenciendo de que estos son imprescindibles para profesionalizar en gran parte nuestro trabajo. Es mas, ahora me acuerdo de algunos proyectos en los que trabajé anteriormente y lo bien que nos habrían venido en el testeo de algunos procesos complejos, la de tiempo que habría ahorrado y sobre todo la tranquilidad que habría aportado al equipo.

De todas formas, aun tenemos algunas lagunas, por lo menos yo no tengo nada claro como se debe mantener un juego de datos coherente con el que hacer pasar los tests, sin que esto lleve mas tiempo que beneficio, por el momento tenemos 2 aproximaciones:
- Almacenar con dbunit un juego de datos (xml, cvs, etc) con unos identificadores reservados (por ej de 1 a 500), e importarlos a BD cada vez que pasemos los tests.
- Usar una BD independiente contra la que ejecutar los tests.
Usaremos la segunda opción aunque insisto, no tengo una postura clara sobre el tema y no termina de convencerme.

Hay quien dice que lo mejor es tener los X registros que necesitamos en xml para cada test de forma independiente, solo esos X registros ni uno mas ni uno menos. Me gusta la idea de tener muy controlados los registros que pruebas y que todo el equipo los conozca, del identificador 1 al 20 entidad en Y estado, del 20 al 40 en Z estado etc etc.

Al final escribir y mantener tests y sus datos de prueba no es gratis, lleva tiempo y creo que no solo cuando empiezas, pero debes convecerte de que es la forma de garantizar un software de calidad, de desarrollar con tranquilidad sabiendo que si haces algo que afecte a otra parte del sistema te vas a enterar antes que tu cliente. No creo que se escriban tests para hacer el desarrollo mas rápido sino para hacerlo mejor.

Recomiendo especialmente un par de podcasts de javahispano sobre el tema:

http://www.javahispano.org/contenidos.item.action?id=1985256&menuId=JH_PODCASTS

http://www.javahispano.org/contenidos.item.action?id=6813316&menuId=JH_PODCASTS

Y habrá que seguir leyendo y buscar mas opiniones de gente con experiencia.

Pasamos a probar la nueva rc1 de gxt2.0.

Sorpresón, las ventanas ya no se cierran, solo se ocultan, y claro esto ya ha provocado debate. Explican que ellos las eliminarán completamente en cuanto se pierda la referencia. Hasta aquí (aunque no acabo de entender el porqué del cambio, bien podrían haber mantenido el close por si la quiero destruir yo mismo! e implementar igualmente el mecanismo de liberación de memoria de los objetos no usados) tampoco voy a reprocharles nada.

Ahora, tengo una ventana, con los 3 típicos botones: minimiza, maximiza, cierra. Necesito de alguna forma distinguir el evento de cierre del de minimizar. Hasta ahora simplemente se implementaban 2 listeners diferentes: windowHide, windowClose. Pero como decimos windowClose desaparece, hemos de buscar otra forma alternativa de diferenciar entre un cierre y un hide, y por defecto el evento generado por botón close de las ventanas no nos da el botón que hemos pulsado, supongo que se les ha escapado.

Finalmente veo 2 opciones:

La primera y mas sencilla es pasar algún parámetro a la ventana en el momento del ocultamiento/mimización (navegando a los fuentes del sistema MDI que implementa gxt veo que esta es la opción que utilizan), por ejemplo:

y ya en el evento hide comprobar si la ventana ha sido mimizada o por el contrario está cerrada.

Y la segunda:
Ya que como deciamos el evento generado por el botón close de la ventana no nos ofrece el botón pulsado, vamos a ocultar los botones por defecto de la ventana y añadir los nuestros.

Primero ocultamos los botones "por defecto":

Ahora añadimos nuestros propios botones, y para close nuestro propio evento pasando un botón (creado exclusivamente con este fin) al método hide, ya que hide solo puede recibir Button y no ToolButton:

Y ahora si, en el evento generado por el ocultamiento de una ventana podemos diferenciar cuando la estamos cerrando o cuando la estamos enviando por ejemplo, a la barra de tareas:

En fin, que no acabo de entender porque eliminan la funcionalidad del close, como decía sería mejor mantenerla e implementar además el mecanismo de liberación de memoria. Se mantendría la compatibilidad y podríamos diferenciar de una forma mas lógica y fiable cuando se produce el cierre, ya que son dos operaciones claramente diferenciadas.

A ver por donde empiezo, que son muchas las novedades/experiencias acumuladas los últimos días sobre gwt, buenas y no tan buenas:

SmartClient

1- El rendimiento de smartclient, sobre todo en ie y equipos poco potentes, deja bastante que desear. Especialmente utilizando grids con muchas columnas. Varios fueron los intentos por solucionarlo: precargar imágenes antes de mostrar componente, activar caché, hacer rollover sobre color de fondo y no sobre imagen, setShowAllRecords(false), personalizar estilo filas setBaseStyle("estilo_filas_grid"). En fin, que no soy el único quejica, aqui un hilo significativo en los foros, el problema parece que está en la raíz.

2- Soporte: 2 caras 1 cruz

Dos problemas de maquetación, y dos envíos a los foros de smartclient.

Cara, una duda sobre la existencia de un flowlayout perfectamente resuelta por uno de los usuarios.

Cruz, un problema al intentar posicionar un DisclosurePanel de gwt dentro de un window de smartclient con posición absoluta, ni una sola respuesta. Finalmente lo solucioné con un SectionStack de smartclient, pero nada de posiciones absolutas.

Otra cara, contacto directo vía mail con gente de smartclient, siempre responden .

3- Integración gwt-smartclient: Al hilo de estos problemas, comentar que la integración de componentes gwt con smartclient no es buena. Así que si elegimos smartclient tendremos que usar muchos componentes smartclient para evitar problemas de maqueta.

De cualquier forma no puede haber queja del soporte.

Gracias a smartclient por ofrecer una librería gratuita sobre gwt como esta. Pero queremos mas y sobre todo mejor, estaremos atentos.

gwt-exporter

Desde javahispano me entero de la existencia de gwt-exporter. Aun existiendo librerías javascript libres (jquery&otras) tan buenas, prácticas, con gran comunidad, etc, es muy interesante la posibilidad de desarrollar una propia librería bajo gwt para que después terceras personas/equipos la usen desde javascript al estilo jquery&otras.

Google Plugin for Eclipse

Desde que hace tiempo probé sin éxito cypal, no habia buscado alternativas y me valía la simple estructura generada por los scripts de gwt. Ahora google publica Google Plugin for Eclipse, tanto para gwt como para App Engine, un nuevo pasito.

Gwt 1.6

Nueva versión de gwt. Aqui lo nuevo, a modo de resumen:

Nueva estructura de proyecto: Bien! se eliminan los (.launch, .compile, .shell) y se añade fichero de tareas ant.

Se sustituyen Listeners por Handlers.

Nuevos widgets, DatePicker, DateBox y LazyPanel, no llegan no ¡queremos mas!.

Creación y activación de eventos nativos.

Mejoras en el Modo Hosted.

Slider

Que gwt todavía no tenga un slider pasa (está en la incubadora). Pero que ext gwt no tenga slider en su versión stable ya es demasiado, si, lo incluyen en su próxima versión 2.0.

Google!, que sepas que echamos de menos nuevos y mejores widgets, ya se que no me escucha pero hay que intentarlo.

Ext GWT nativo

Me gusta que la implementación de extgwt sea de forma nativa sobre gwt y no se utilicen librerías externas. En general (aun con los problemas que comenté en el post anterior) la integración con gwt está mas conseguida y el rendimiento es mucho mejor que en smartclient, aunque me pese es así.

Sobre el semestre en la uoc, lo mas destacable: TALF2 me mata.

Sobre El quinto día, mantengo lo dicho quitando el último capítulo (que pesado).

Me he enganchado desde el principio a El Ocho, imprescindible para los jugones del ajedrez

Desde que hace algo mas de 1 año dejé de luchar a fondo con el html+css (ahora priorizamos funcionalidad a diseño) no me había topado con un problema tan tonto, de esos tan tontos que te tocan lo que ya sabeis. Un puñetero punto y coma.

El caso es que hace un par de semanas que he decidido retomar mis pinitos de hace 9 meses con gwt, esta vez algo mas en serio y centrandome sobre todo en la construcción de la interfaz.

Todavía no había escrito nada sobre gwt, entre otras cosas porque no tengo tiempo, pero vamos, que dando una vuelta por la documentación oficial la idea queda clara. Un framework que pretende hacer mas sencilla la generación de la interfaz para aplicaciones web (y sobre todo mas próxima a los programadores que no se llevan bien con el html+css+javascript, cuando menos la mayoría que han programado siempre en escritorio).

La idea básica es programar en java (como para swing) y mediante el compilador gwt generar toda la capa cliente html+css+javascript. Pero bueno dejamos para otro post generalidades sobre gwt, y vamos con mi estúpido problema.

Primero probé gwt sin más, componentes muy muy básicos, pero que funcionan.

Continuamos con gxt, componentes muy elaborados, demostración de interfaz MDI, tablas, formularios, etc. Aunque a veces se hace un lio con la generación de estilos, y otras no hace caso a los tamaños que inyectas desde java y debes atacar directamente al css generado (es un peligro). Además desde hace un tiempo la versión comercial es de pago.

Llegamos a smartgwt, componentes muy parecidos a gxt, un wrapper sobre smartclient, esta última de pago, pero parece que la versión gwt es gratuita. La verdad: menudo jaleo de licencias, cada vez entiendo menos. Pruebo esta versión, combinando con controles de gwt nativos para depender lo menos posible de una tercera librería.

Por el momento me gusta smartclient (incluso el codigo generado no parece ser tan "cochino" como el de gxt), sigo con las pruebas..., inserto un DisclosurePanel dentro de un Window de smartgwt, problema, aparece con un height que yo no pongo, no se de donde sale (el problema de gwt cuando las cosas no salen a la 1ª). Le pongo un tamaño dpContentSearch.setHeight("40px;"), ni caso. Además no es el height del DisclosurePanel sino el del contenedor, el del layout del Window de smartgwt. Cambio el DisclosurePanel por un HorizontalPanel, nada, lo cambio por un Canvas de smartgwt a ver si el problema va a ser la mezcla de componentes, tampoco.

Se me acaban las ideas, navego por los foros de smartclient, por los fuentes de los diversos componentes buscando algún método que lo solucione, vueltas y mas vueltas... ya por desesperación y tras largo tiempo intentando mas cosas cambio de nuevo el 40 y funciona!, cosa mas rara. Intento buscar la diferencia... el punto y coma del 40, dpContentSearch.setHeight("40px") no, no es lo mismo. Y que conste que el ";" no era ninguna tontería, por ejemplo en gxt se permite, incluso se permite insertar un "40px !important;", por eso este método recibe un string, además de para especificar el tamaño en la unidad que necesites.

Isa se ríe de mi (parece q a las químicas no les pasan estas cosas), me piro a la siesta, es domingo y toca descansar, aunque con este sentimiento de rabia-euforia-emoción-soyunpocotonto es imposible, mejor leo y punto: "El quinto día (Franz Schätzing)" ahora que llego al final me he enganchao .

Al final les envie una notificación de lo que me había pasado con la codificación de lineas (en un penoso inglés, tengo q ponerme con el ): http://code.google.com/p/gmaps-api-issues/issues/detail?id=1081, que está aceptada.

Efectivamente parece que el paso 2 está mal documentado, no se redondea a la baja, en inglés ya solo tienen:

Take the decimal value and multiply it by 1e5, rounding the result

en lugar de:

Take the decimal value and multiply it by 1e5, rounding down the result

También dicen:

The visual results should look pretty much the same for the viewer, however.

Pero claro un pequeño error sobre otro pequeño error... al final es un gran error. Recordemos que cuando codificamos una polilinea el único punto original codificado es el primero, para los siguientes simplemente se codifica la distancia desde el punto anterior, con lo que cualquier tipo de error se multiplica y al final las diferencias pueden ser enormes.

Debido a esto y que me encontrado con otras pequeñas diferencias entre la herramienta de codificación y mi algoritmo, finalmente he decidido no gastar ni 1seg mas de mi escaso tiempo. Representaré las lineas con los puntos originales sin codificación, y codificaré toda la lógica de carga y presentación de las diferentes líneas en base a posicion del mapa y zoom básicamente.

Llevo ya un buen tiempo jugando con google maps, es divertido, y si a eso le sumamos RoR, mas divertido todavía :-).

Para dibujar líneas sobre un mapa se utiliza el objeto GPolyline. Para construir esta línea lo que hacemos es unir puntos, representados mediante la clase GPoint, puntos que se construyen con 2 parametros (latitud, longitud). Bastante básico todo.

Imaginemos que tenemos una Polilínea con muchisisimos puntos, llegará un momento en el que nuestro navegador será inoperativo, demasiada carga javascript, demasiado lento. Además, seguro que con un zoom muy lejano no necesitaremos dibujar tantos puntos, mmm interesante, dependiendo del zoom dibujamos unos puntos u otros, a mas detalle mas puntos. Y además, solo necesitamos dibujar los puntos que se representen sobre la zona del mapa que visualizamos, aunque la polilinea recorra todo el planeta, si solo veo Galicia no quiero cargar la parte de la polilinea que pasa por Francia.

Todo esto lo podemos hacer manualmente registrando eventos de zoom y movimiento sobre el mapa, y cargando por llamadas callback ajax las partes de las lineas que necesitemos.

Pero hay otra forma, con la que además disminuimos la carga de javascript de nuestro navegador, que consiste en codificar, mediante este algoritmo propuesto por google, todos los puntos con los que dibujaremos nuestra polilínea. En esta codificación también incluiremos la definición de sobre que niveles del zoom quiero dibujar cada uno de los puntos.

Hasta aqui todo bien, nos ponemos a traducir el algoritmo (que por cierto podía estar mejor documentado), llegamos al punto 2:

2. Multiplica el valor decimal por 1e5, redondeando el resultado a la baja:
Fácil, -179.9832104*10^5=-17998321.04, redondeamos a la baja y nos queda -17998321.
Seguimos todos los pasos y al final nos queda ese punto codificado como: `~oia@

Aqui los pasos:

Los creo, pero debo asegurarme de que mi algoritmo está perfectamente traducido.

Así que ahora que mi algoritmo funciona con el punto anterior, probemos con otros, estemos seguros de que funciona bien. Tenemos una utilidad del mismisimo google para que codifiques tus puntos de forma manual, codificamos el mismo punto -179.9832104 en la longitud claro, y... uy, volvemos a hacerlo, vaya, resulta que el punto devuelto no es el mismo: b~oia@

Veis en verde el punto en la longitud, y abajo en verde también ya traducido, no es el mismo que el anterior:

Le damos una y otra vuelta, probamos una y otra vez, y finalmente encontramos el motivo, parece el rendondeo, resulta que en la explicación del algoritmo nos dicen que debemos redondear a la baja, y sin embargo aqui estan redondeando al alta, no tiene otra explicación, debe ser eso. Vamos a preguntarles, ya os contaré.

Tanto los componentes como los helpers están diseñados para extender las funcionalidades que el propio núcleo cake nos ofrece. La diferencia? bien sencilla. Mientras los componentes añaden lógica de negocio a nuestro proyecto, los helpers añaden lógica de presentación.

Componentes:
Existen multitud de componentes que podemos descargar y utilizar: Sending Email With PHPMailer, Integrate CakePHP with Kcaptcha, Google Geocoder, LastRSS CakePHP Component, Pagination Component, etc. Y otros que ya vienen incluidos con el núcleo cake: AuthComponent (Gestión y autenticación de usuarios), RequestHandler (Obtener información de las peticiones http), CookieComponent (Gestor de cookies), AclComponent (Access Control List), EmailComponent (Envio de mails), SecurityComponent (Incrementar la seguridad de tu aplicación), SessionComponent (Gestor de session). Y podemos crear nuestros propios componentes para cumplir diferentes requisitos:

Crear un nuevo componente para cakephp es muy sencillo. Basta con crear un fichero en app/controllers/components/fichero.php con una clase nombrada FicheroComponent que tendrá una variable $controller y un método:

Luego para hacer uso de un componente en uno de nuestros controladores simplemente lo añadimos al array

y ya lo tendremos disponible como

Aqui tenemos un buen ejemplo de uso del json component.

Helpers:
Respecto a los helpers también los tenemos incluidos en el núcleo cake: html (ayuda a contruir tags html), form (ayuda a contruir formularios), number (ayuda a formatear numeros), timer (ayuda a formatear fechas), xml (simplifica la construcción de documentos xml), ajax (uso de ajax mediante prototype). Su uso es tan sencillo como:

Al igual que los componentes también podemos desarrollar nuestros propios helpers, aqui tenemos un buen ejemplo donde se crea un helper para autocompletar un input text mediante ajax .