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.

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.

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.

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

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 .

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

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.

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

Después de 2 días iniciándome en RoR, en realidad de rails apenas he visto nada todavía, simplemente he preparado el entorno, familiarizado con ruby, me peleé un poco con las gemas y mysql, y ejecuté algunos de sus comandos para crear una aplicación rails, modelo, controlador.

Pues eso, que después de estos 2 días y por razones que no vienen a cuento he estado probando maven (desde el curso de j2ee tenía pendiente echarle un vistazo). La experiencia esta siendo muy satisfactoria, lejos de la complejidad de la que muchos compañeros me habían hablado.

Maven al igual que ant es una utilidad para... automatizar muchas de las tareas en el desarrollo de un proyecto (compilar, desplegar, descargar librerías, pasar tests de unidad, empaquetar, etc etc). Si conoceis ant estaréis pensando que no es nada nuevo, en realidad se podría decir que es una evolución de ant, incluso podemos integrar las dos utilidades para ejecutar tareas ant desde maven.

Comentar que un proyecto maven tiene una estructura global mas o menos fija (que se puede variar, pero ni lo he probado ni lo necesito). Cuando creamos un proyecto mediante la linea de comandos mvn archetype:create -DgroupId=net.jsanroman -DartifactId=aprendiendoMaven, o añadiendo el parámetro -DarchetypeArtifactId=maven-archetype-webapp para un proyecto web, se crea una estructura como la que podeis encontrar en la documentación.

Maven, además de la maravillosa funcionalidad de descarga automática de jars, bien de un repositorio externo, o de nuestra propia red local (típica situación de un equipo de desarrollo de muchas personas sobre un mismo proyecto), tiene preparadas para nosotros multitud de tareas y plugins, por ejemplo el despliegue de nuestro proyecto en un tomcat mediante el tomcat-maven-plugin, simplemente ejecutando mvn tomcat:deploy, aunque antes tendremos que configurar ciertos parametros en el fichero de configuración de maven pom.xml:
dentro de proyect>build:

Configuramos por ejemplo en path de la aplicación a desplegar, el usuario y clave de nuestro manager de tomcat, y la localización de nuestro fichero war a desplegar, aquí mas documentación.

Para que maven sepa que jars debe descargar para nuestro proyecto también lo indicaremos en este mismo fichero pom.xml:

Le indicamos que se descargue la api de servlets. Tenemos un listado completo de librerias en http://mirrors.ibiblio.org/pub/mirrors/maven2/.

Maven se integra con diferentes ide's: netbeans, idea, eclipse. Yo solo he probado con eclipse, para el que hay varios plugins, aunque sin duda para mi el mejor es m2eclipse. No cometáis la misma torpeza que yo, que con las ansias de avanzar ni me fijé en el tipo de errores que daba su instalación, y simplemente que depende de otros plugins para poder ser instalado, aquí tenéis la lista http://docs.codehaus.org/display/M2ECLIPSE/Installation+Requirements.

Aunque todavía me quedan muchas cosas que ver de maven, métricas o integración continua, ya tengo lo básico en funcionamiento, y aquí dejo los 4 comandos básicos, en realidad son "mi recordatorio" que soy muy despistado :$:

• Creamos nuevo proyecto: mvn archetype:create -DgroupId=net.jsanroman -DartifactId=aprendiendoMaven -DarchetypeArtifactId=maven-archetype-webapp
• Compilamos proyecto: mvn compile
• Empaquetamos proyecto: mvn package
• Copiar jar de proyecto a repositorio local de maven: mvn install
• Desplegar proyecto web en tomcat: mvn tomcat:deploy
• Generar sitio web (si si como el de maven): mvn site:site

Después de probar varios plugins antispam me he quedado con Math comment spam protection, de lo malo, mejor una simple pregunta sobre una suma matemática básica en texto plano (1+1,3+2,etc), que la típica imagen deformada, muchas veces imposible de descifrar.