Una búsqueda rápida en google arrojó varios resultados sobre como utilizar la magia del metaClass de groovy para mockear manualmente los objetos y métodos necesarios, pero hay mejores maneras de hacerlo.

Desde no se que versión de Grails existe el método mockConfig de la clase GrailsUnitTestCase de la cual deberían heredar todos nuestros test unitarios.

Lamentablemente no encontré mucha información sobre como usar este método por ningún lado. Solo había encontrado un blog llamado 418 I’m a teapot (en un artículo medio viejito) en el cual decían que no lo habían logrado hacer funcionar y por eso continuaban utilizando metaclass

Por suerte haciendo algunas pruebas descubrí una forma de hacerlo trabajar para mis necesidades. El secreto es que este método no acepta la sintaxis jerárquica (perdón, no se el nombre técnico) en el config, sino que debemos hacer todo más sencillamente.

Por ejemplo, en lugar de escribir

mockDomain("""
    grails {
        paypal {
            server = "https://www.sandbox.paypal.com/"
        }
    }
""")

lo que debemos escribir es

mockDomain("""
    grails.paypal.server = "https://www.sandbox.paypal.com/"
""")

De esta manera, y accediendo a la configuración por medio del ConfigurationHolder en mi aplicación, no he tenido mayores problemas.

Por defecto, no tiene soporte para el lenguaje Groovy, pero es fácilmente configurable, e incluso sin necesidad de permisos de adminsitrador, permitiéndonos configurar nuestor ambiente de trabajo, sin modificar la configuración de los demás usuarios.

Para esto debemos descargar el bundle con el coloreo de sintaxis, tipos mime y otras cosas del sitio http://www.grails.org/Gedit

En esa misma página podremos encontrar instrucciones para instalarlo, que requieren de permisos de administrador. Pero combinando un post anterior en este mismo blog, sobre como hacer que gedit abra archivos tpl como si fueran archivos php y algunos otros tips más, podremos instalarlo sin necesidad de permisos especiales.

Luego de descompactar el archivo descargado, copiamos los directorios plugins, snippets y styles a la carpeta ~/.gnome2/gedit

Para arreglar el coloreo de sintaxis y enseñarle a gedit la existencia de groovy debemos crear la carpeta (si no existe) ~/.local/share/gtksourceview-2.0/language-specs y copiar en ella los dos archivos terminados en .lang que descompactamos.

Despues creamos el archivo ~/.local/share/mime/packages/Overrides.xml (y las carpetas necesarias, si no existen) y agregamos en ese archivo el contenido de los dos archivos xml que se encuentran en el bundle.

El contenido final del archivo será similar a

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
	<mime-type type="text/x-groovy">
		<sub-class-of type="text/x-java"/>
		<comment>Groovy Source File</comment>
		<glob pattern="*.groovy"/>
	</mime-type>
	<mime-type type="text/x-groovy++">
		<sub-class-of type="text/x-groovy"/>
		<comment>Groovy++ Source File</comment>
		<glob pattern="*.gpp;*.g++"/>
	</mime-type>
	<mime-type type="text/x-gsp">
		<sub-class-of type="text/html"/>
		<comment>Grails GSP File</comment>
		<glob pattern="*.gsp"/>
	</mime-type>
</mime-info>

Finalmente, para que el sistema reconozca nuestros cambios, debemos actualizar la base de datos de tipos mime, ejecutando el comando update-mime-database ~/.local/share/mime

Con esto, al abrir el próximo archivo de groovy, deberíamos tener coloreo de sintaxis funcionando correctamente.

Se pueden seguir haciendo otras cosas como habilitar bash completion, pero lo dejaremos para otra oportunidad.

Justamente por esas características necesitábamos tener los contenidos en diferentes idiomas y seleccionar aspectos del sitio en base al país de origen. En otras palabras, nos interesaba decirle a los brasileros cosas que son importantes para ellos y no cosas que sean importantes para los italianos. (por decir un ejemplo)

La solución vino de la mano de algunas herramientas que Grails, de la mano de Spring, nos da. Entre las clases están:

org.springframework.context.i18n.LocaleContextHolder as LCH
org.springframework.web.servlet.support.RequestContextUtils as RCU
org.springframework.web.context.request.RequestContextHolder as RCH

Lo más cuiroso es que, aunque estas clases parecieran ser las de Spring mismo… por detrás, hay cosas de Grails ocurriendo y, como para citar un ejemplo el

org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes()

que debería dar un org.springframework.web.context.request.RequestAttributes internamente está dando algo diferente, directamente provisto por Grails y por supuesto gracias a su magia con mucha más funcionalidad, llamado GrailsWebRequest.

A pesar de mi actitud quejosa tengo que aceptar que atar confiar en una estructura ya formada, probada y sostenida en tecnologías como Spring era mucho más confiable que terminar transfiriendo el valor “request” en todas las clases de negocio y controladores de nuestro proyecto.

Gracias Grails.

pd: Está más que claro que no es la única clase de Spring que Grails está encapsulando, así que el día de mañana, si llegasen a tener un problema de este tipo recuerden que hay luz del otro lado del puente.

Particularmente lo que me molestaba tener que actualizar eran los tipos MIME que identifican un determinado archivo, con un determinado tipo y gedit como nautilus utilizan para saber como abrir cada archivo, de que forma colorearlo, etc. Para modificar ese directorio se necesita permisos de administrador y siempre me pareció que debería haber una forma de hacerlo desde mi cuenta de usuario limitado.

Hoy, que estaba trabajado con PHP, queria abrir unos archivos de Smarty que tienen extensión tpl, y que se colorearan automáticamente como html, que es el lenguaje más cercano que reconoce (o al menos de los que vienen por defecto) y decidí buscar en internet una forma de hacerlo y encontré dos páginas, por un lado el blog de c3b en un artículo titulado Alternative method for opening Smarty templates with HTML syntax highlighting in gedit y también en la página de gnome bajo el nombre Modifying MIME types

Combinando el conocimiento de ambos sitios, logré que al hacer doble-click sobre un archivo tpl, se me abra automáticamente el gedit (y no firefox!) y se me coloree automáticamente la sintaxis como PHP

¿Cual fue el procedimiento? Fácil.

Lo primero que hice fue crear la carpeta ~/.local/share/mime/packages

En esa carpeta creé un archivo llamado Overrides.xml con el siguiente contenido

<?xml version='1.0' encoding='utf-8'?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
    <mime-type type="application/x-php">
        <glob pattern="*.tpl"/>
    </mime-type>
</mime-info>

Luego ejecuté el comando update-mime-database ~/.local/share/mime

La lógica detras de este procedimiento, es que en el archivo Overrides.xml puedo crear nuevas asociaciones, o modificar exisntes. En este caso en particular, se le informa al sistema que los archivos .tpl son archivos PHP, y por lo tanto lo colorea automáticamente como PHP

Y todo esto sin usar sudo ni una sola vez

Esto se debe a una incompatibilidad entre el Plugin  de VMware y esta versión de Firefox, lamentablemente no hay forma de hacerlo funcionar dentro de la ventana del explorador, pero es fácil de ejecutar.

Para ejecutarlo basta ejecutar el archivo vmware-vmrc que se encuentra en el directorio ~/.mozilla/firefox/<perfil>/extensions/VMwareVM

Donde <perfil> es el directorio donde se guarda e perfil del usuario.. a menudo será el único directorio dentro de ~/.mozilla/firefox y si hay más de un directorio, seguramente sabrás como identificarlo

Aparecerá una pantalla donde deberás ingresar la url o ip del servidor (y el puerto, ejemplo 127.0.0.1:8333), luego listará todas las máquinas virtuales disponibles… y listo.. estarás controlando el sistema.

Luego de hacer esto te descepcionaras al ver que no anda parte del teclado. La solución a esto más facil que encontré, aunque no arregla todas las teclas, si arregla los cursores y lo que necesito para poder terminar de instalar el sistema es crear en el directorio ~/.vmware un archivo llamado config con el texto xkeymap.nokeycodeMap = true

Luego de esto, si todo sale bien… ya podremos utilizar las maquinas virtuales de vmware sin problema desde nuestro equipo

Por un lado está Prototype, que es el clásico, más usado (a mi parecer) y por sobre manera sencillo.
Por otro lado, aparece también YUI la alternativa de Yahoo que en general se dice que es super rápido, pero al mismo tiempo se propone como gran patrón de todos usando un modelo de objetos interesante y de por si complejo por con una excelente documentación y funciones de vista.
Y, claro, por final y no por eso menos importante, está jQuery, quien aparecería, según nuestro criterio como el gran vencedor de toda esta lucha. ¿Por qué? porque es sencillo, es práctico, es escalable, es rápido y al estar orientado a plugins permite extenderlo hasta el infinito y más allá (si, me copié la cita de Buzz Lightyear), por eso en esta ocasión, además de recomendar el uso de jQuery como framework principal de javascript, les sugiero que lean este link que contiene muchísimo material de estudio y referencia que estoy seguro lo van a encontrar interesante.

¡Espero les sirva!

Si bien Flash no me gusta y creo que está en proceso de desaparecer, el no tener una versión nativa de 64 bits me es molesto. Por un lado necesito instalar un montón de dependencias, que lejos de ayudar molestan, para poder ejecutar la versión de 32 bits, y además si no lo hago no puedo jugar al Gran DT (ni acceder a casi el 30% de las páginas web).

Hoy, aun configurando la beta de Ubuntu 10.10 Maverick, me puse a buscar si ya existía algun Flash de 64bits y me llevé la grata sorpresa. Además de volver a publicarse en el sitio de Adobe (para linux, mac y widows) , encontré un PPA para poder instalarlo utilizando apt-get

Basta con los siguientes comandos

sudo add-apt-repository ppa:sevenmachines/flash
sudo apt-get update && sudo apt-get install flashplugin64-installer

Para mayor información los remito al blog de OMG! Ubuntu! de donde saqué esta información

Ayer había visto que mi compañero Facundo estaba utilizando Firefox 4 Beta 5,  y me pregunté cuales eran las diferencias y mejoras que se planteaban agregar en esta nueva versión de mi explorador favorito. Por este motivo hoy leí los release notes que figuran en la página de mozilla y entre muchos cambios que nombran uno me llamó la atención y decidí escribir algunas líneas al respecto aquí

La característica en cuestión es CSS :visited selectors have been changed to block websites from being able to check a user’s browsing history. Lo cual se traduce más o menos como El selector :visited de CSS ha sido cambiado para impedir que los sitios puedan chequear las páginas visitadas del usuario

La génesis del problema es que, actualmente, una página web pueda mostrar una larga lista de links y aplicarles por medio del selector :visited un estilo que diferencie los links visitados de los no visitados. Y luego utilizando algunas funciones JavaScript determinar cuales aparecen con un estilo u otro e informarselo al servidor.

En mi humilde opinión, no es un bug que requiera ser arreglado, sinó mas bien una característica y comportamiento de los estilos CSS, sin embargo entiendo los motivo (phishing y malas intenciones) para que se quiera bloquear este posible vector de ataque a la privacidad de un usuario.

Sin embargo, lo que más me llamó la atención es la forma en que plantean resolverlo, que básicamente son

1. Algunas funciones de javascript mentirán en sus resultados para no delatar las páginas visitadas
2. Limitar muchísimo los estilos que se podrán aplicar al selector :visited reduciéndolos básicamente a sólo cambiar de color

Ante semejante limitación, en esa misma página, se alzaron las voces a favor y en contra con argumentos muy interesantes de ambos lados.

Desde mi posición de ignorante amateur, la idea que Javascript mienta si bien en primera instancia no me pareció mala, me gustó mucho más el que en lugar de mentir se generen errores cuando se intenten acceder a propiedades que deberían ser limitadas.

Si bien muchas páginas que actualmente funcionan correctamente, comenzarían a mostrar errores por culpa de javascript, no creo que existan muchas que realmente necesiten acceder a las funciones que están involucradas. En cambio el mentir en lo que retorna una función me parece simplemente equivocado.

Es, sin embargo, el segundo punto que nombro el que mas me inquieta

Aunque no soy un diseñador experimentado he utilizado en varias ocaciones el pseudo selector :visited para agregar información al usuario resaltándole los links no visitados de los que ya ha estado navegando.

En algunos casos esto lo he realizado utilizando diferentes colores, o subrayando el texto, pero en muchos mi estrategia fue agregar un borde, o cambiar el tamaño de una tipografía o incluso pasandola a mayúsculas o minúsculas.

Ninguna de estas acciones funcionará con el nuevo modelo, por lo que algunos sitios dejarán de funcionar correctamente. Afortunadamente este cambio no hará al sitio inusable, pero si lo afectará visualmente. e incluso limita mis posibilidades de diseño.

Por otro lado, como bien dicen en el sitio de mozilla, otros engines de renderización html, como WebKit (el  utilizado por Google Chrome) están implementando las mismas restricciones por lo que es algo bueno que todos tomen las mismas medidas (sería muy desagradable y problemático que algunos tiren errores, otros mientas, etc) y además deberemos convivir con estas limitaciones, porque si la mayoría de los exploradores las adopta, serán unas limitaciones que llegarán para quedarse.

Esperemos que no afecte tanto como algunos dicen, aunque supongo que afectará más de lo que los optimistas piensan. De mi parte me adaptaré a los tiempos actuales, y trataré de ir evitando el uso de estas características desde ahora.

Hasta hoy, no habia una forma que realmente me gustara de realizar esto, ya que o eran muy complejas, o no pasan la prueba de XHTML válido. Estas eran a pesar de la especificación agregar los atributos a los tags html directamente y luego recuperarlos utilizando getAttribute, o utilizando alguna librería de javassscript (o javascript puro) para realizar la misma tarea, pero 100% en el lado de javascript y asi pasar las validaciones de html.

Pero hoy investigando sobre HTML5 encontré que finalmente definieron una manera estructurada de lograr este objetivo. Así que a diseñar paginas HTML5 se ha dicho

Rápidamente, todos los atributos que se definan con el prefijo data- se conciderarán validos y como datos costumizados, que no afectan la renderizacion del sitio. Justo lo que quería !

Mas información pueden encontrar en los sitios que me base los cuales fueron JavaScript Kit, el blog de John Resig y también en la pagina de referencia formal, o sea la especificación HTML5 (que aun se encuentra en draft)

Aunque me parecen maravillosas noticias, concuerdo igualmente que esta especificación, en el futuro y cuando se popularize su uso va a llevar a un caos de colision de nombres, como indican en la página html5Doctor

Al margen de custom-data, otra cosa que estoy investigando y espero pronto usar para poder comentarla en este blog (aunque aun no he tenido la necesidad de hacerlo) es la especificación sobre microdata.

• comentarios en los mensajes personales de nuestros amigos
• vemos fotos de personas que ni conocemos, ni nunca vimos personalmente pero nos divertimos viendo qué es de su vida (?)
• “nos gusta” o “no nos gustan” cosas que en realidad no nos interesaron nunca ni mirar
• relaciones? resulta que ahora mi estado amoroso en facebook es real y muy importante para mi circulo de amigos
• tengo una granja y necesito que mis amigos la vean y ayuden a cultivarla

Yo tengo en mente que facebook es una genial herramienta para conectarme con gente que no veo diariamente o que está a una distancia tan grande que me es imposible mantener contacto… como gente que conocí de viaje, amigos del secundario (con los que he mantenido contacto y organizamos juntadas de vez en cuando) o personas que están en el exterior. Hasta es bueno para hacer anuncios a tus amigos de forma que se enteren en que andás por estos días… pero, vamos… tampoco vamos a convertirnos en facebook adictos y que todo lo que nos pase sea exclusivamente a través de ahí! De hecho ahora nos encontramos con que tenemos: buzz, twitter, facebook, orkut… uff… Estos videos, a mi parecer, nos muestran un poco en que nos está convirtiendo facebook… ¿queremos terminar así?

Ahí van los links

• http://tv.gawker.com/5512185/south-park-explains-everything-that-is-annoying-about-facebook
• http://www.youtube.com/watch?v=OiqHXPZwkYk