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.

Bastante tiempo sin escribir ya. Desde la última vez: unas cortas y merecidas vacaciones, comienzo de un proyecto muy ilusionante del que espero hablar algún dia (lo contrario sería una mala noticia), mucho trabajo, y por último una gran noticia pero que me trae en vilo últimamente. En fin que todo a su debido tiempo e intentando mantener la cabeza bien fría.

En mi macbook no tengo ningun servidor de smtp instalado, ni quiero si no es absolutamente necesario. Por ello que para hacer diferentes pruebas de envio de mail desde local utilizo servidores externos. Tengo una cuenta creada en google para este fin, en este caso concreto utilizo cakephp, y ni el componente que este trae por defecto ni phpmailer pueden conectarse con las cuentas gmail al no soportar TLS (Trasport Layer Security), protocolo de autentificación utilizado por gmail.

Buscando otras opciones me encontré con SwiftMailer, y aunque sería sencillo desarrollar un componente que haga uso de esta librería ya lo han hecho por nosotros http://bakery.cakephp.org/articles/view/swiftmailer-component.

Este componente que nos descargamos para cakephp usa sendmail por defecto, pero si lo que necesitamos (por ejemplo una vez subamos a producción) es simplemente usar la función mail() de php, SwiftMailer nos ofrece un wrapper sobre la misma mediante la clase Swift_MailTransport.

Una comparativa entre jquery y mootools http://jqueryvsmootools.com, de uno de los desarrolladores de mootools, seguro que no es del todo objetiva, pero me ha gustado. La idea general:

jquery enfocado a manejo del dom, ellos mismos dicen:

“jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.”

mootools es mas un framework javascript, con el que sigues escribiendo javascript pero de la forma que consideran adecuada los desarrolladores de mootools, ellos dicen:

“MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.”

Mootools hace mas divertido trabajar con Javascript. Jquery hace mas divertido trabajar con el DOM.

Ninguno es mejor sino que cada uno tiene un cometido diferente. La popularidad y éxito de jquery radica en que la muchos desarrolladores web utilizan javascript casi exclusivamente para el manejo del doom, y para ello esta librería es la mas sencilla.

Curva de aprendizaje y comunidad: de largo la curva de aprendizaje es mucho menor con jquery y seguramente debido a esto también es la que tiene mayor comunidad de usuarios.

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 .

¿Que eres de los que todavía no puede pasar de los prototipos a papel y lapiz? ¿Estas cansado de dibujar siempre el mismo marco (ventana, barra direcciones, pestaña) de tu navegador?

He aquí la solución

Vale que son 29$ y solo trae 45 páginas con navegador y 15 con popups, pero no me digais que no quedarían curiosos los bocetos.

http://www.merchline.com/paranaiv/productdisplay.8328.p.htm

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.