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.

Hace algo mas de 6 meses que cambié mi trabajo anterior, teletrabajo, bien remunerado y con un stress aceptable en una mediana empresa, dedicada al desarrollo de un producto de software para realizar reservas de viajes (negocio complejo donde los haya), a formar parte del equipo de uno de los proyectos de ecommerce del año, de una de las empresas mas importantes del sector textil.

Esto trajo consigo mi primer cambio de residencia, de Gondomar a Arteixo, mi primera experiencia viviendo solo, la primera buscando alquiler, y así un largo etc.

Hasta ahora y a pesar de haber tenido momento buenos y malos (algún día me reiré de ellos), siempre he tenido la sensación de haber hecho lo correcto, de no haber dejado pasar la oportunidad de participar en un proyecto tan importante, y sobre todo la convicción de que es mejor arrepentirse de haber tomado una decisión así que de lo contrario.

El subproyecto que me han asignado (que se encargará de la parte logística del macroproyecto) toca un sinfín de tecnologías y herramientas del mundo j2ee, muchas de ellas nuevas para mi, por lo menos a este nivel: spring; hibernate; ejb3; junit; jms (mq); websphere; jetty; maven; sonar; bamboo, rad. En definitiva mucho j2ee, mucho ibm y prácticas ágiles.

Por lo demás estamos entrando en la fase final de http://twitter.com/mitwiz espero que muy pronto podais comenzar a probarlo, que tengamos un feedback real y sepamos si estamos en buena linea o no, si os gusta o creeis que es “otro mas” una perdida de tiempo por nuestra parte :$.

PD: A finales del año pasado los grandes “gurús” vaticinaban que este sería el año del ecommerce y de android: Yo tb creo que esté será el año de ecommece (http://twitter.com/#search?q=%23ecommerce), pero este y el siguiente, y el siguiente… ¿De android? veremos como avanzan y sobre todo con que nos sorprende apple y su nuevo iphone.

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.

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.

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 .