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.

Hecho este descargo, el motivo fue que hice un pequeño programita que escribía en un archivo, para ello me basé en la ayuda de Microsoft que utilizaba el keyword using de la siguiente manera

using(StreamWriter w = new StreamWriter("BuildAll.sql")) {
// hago lo que quiero con el writer
}

Un poco tardíamente (ya que esto existe hace varios años)  me surgió la duda de para que servía realmente using. El saber popular dice que es para asegurarse que se liberan los recursos que podrían haberse reservado, pero esta explicación no era suficiente para mi y quería saber realmente como funcionaba.

Consultando en internet encontré en CodeProject el artículo titulado The “using” Keyword in C# en el cual el autor comenta  su investigación sobre el asunto. Recomiendo a cualquiera que le interese un poco el funcionamiento interno de las cosas que le pegue una leida a ese artículo.

En resumen lo que dice es que lo que hace este keyword es crear un bloque try..finally, en donde como última acción se realiza un dispose del objeto que figura en el parámetro del using. Y que si la clase que se esta intentando limpiar no implementa correctamente la interfaz IDisposable no sirve de mucho.

En fin, esto más que nada me pareció una curiosidad que a otros les parecio interesante que escribiera aquí.

Pero cuando intenté llevar a la práctica esto, descubrí que no quería crear una clase nueva para tener estos métodos, sino que quería que estén en la misma clase. Esto me planteaba un problema. Necesitaba mocker el método que no quería que se ejecutara, pero no sabía si podía mockear una clase en la cual había un método que si quería testear.

La respuesta fácil es SI, se puede, pero hay una limitación. El método que se quiere mockear hay que hacerlo utilizando metaClass. No se puede utilizar demand, como con los mocks normales, sino que se debe si o si utilizar metaClass.

Uno puede decir, que para eso no hago ningún mock, y simplemente utilizo metaClass para pisar el método en cuestión, pero lamentablemente, como dicen en muchos otros blogs, hacer eso no es seguro, y puede afectar el resultado de otros tests. (de hecho en mi se veía el error en los test de integración que comenzaron a fallar y no entendía por qué)

Basta con llamar a mockFor sobre la clase que se quiera testear, y luego se puede utilizar metaClass tranquilamente para cambiar esa clase, que cuando se termine el test los cambios se revertirán normalmente.

Se que mucho tal vez no se entienda, asi que dejaré un pequeño ejemplo comentado aquí

Quiero testear el método agregar de la clase DestacadoService. Este método internamente llama al método buscarDestacado el cual utiliza bastante hql para realizar su función, el cual no funciona en pruebas unitarias, entonces para realizar el test de agregar se necesita hacer algo similar a lo siguiente:

mockFor(DestacadoService)
DestacadoService.metaClass.buscarDestacado = { pais, tipo, id -> return null; }

def service = new DestacadoService()
def r = service.agregar(pais.argentina, tipo.principal, 'mi destacado')

Como se puede apreciar, en la línea 1 llamamos a mockFor sobre la clase que queremos mockear
En la línea 2, utilizamos metaClass para cambiar el método (y retornar algo estático que no use hql ni nada)
En la siguiente línea de código instanciamos la clase que contiene el método que queremos testar
Y finalmente, en la última lo ejecutamos

Haciendo esto nos aseguramos que luego del test el cambio sobre la clase causado por la modificación del metaClass sea revertido y no afecte al resto de los tests.

Exactamente lo mismo se debe hacer cuando se quieren modificar métodos que estén en clases de dominio. Solo que en lugar de utilizar mockFor se puede utilizar mockDomain

En grails hay principalmente dos tipos de tests. Unitarios y de Integración. Los primeros se ejecutan muy rápido pero no cuentan con todo el entorno de grails especialmente hibernate, y los segundos demoran mucho más en su ejecución, pero contamos con todas las funcionalidades de grails.

Según mi humilde opinión, debemos intentar hacer la mayor cantidad de tests posibles utilizando pruebas unitarias, ya que en mi experiencia por ser tan lentos los tests de integración, terminamos sin usarlos.

Pero nuestra intención de usar test unitarios lo más posible, se golpea contra un muro de concreto cuando intentamos testear métodos que utilizan Criterias o Hql, ya que al depender de hibernate, el cual no está disponible durante las pruebas unitarias no hay forma de hacerlos funcionar.

Un “tip” es intentar utilizar tan poco estas funciones como sea posible, y cuando no queda otro remedio que usarlas, intentar centralizar todo el código en algunos métodos que únicamente se encarguen de realizar estas consultas, los cuales serán probados con test de integración.

Si todo este código lo ponemos en una clase diferente, entonces podremos mockearla para las pruebas unitarias y el resto de nuestros métodos que no dependen de hql ni criterias, podrán ser testeados ya que se limitarán a invocar los métodos problemáticos sobre un mock, y problema resuelto.

Sin embargo a veces no queremos poner estos métodos en otra clase, sino que deseamos que sean métodos de la misma clase que estoy estoy testeando, o los métodos se encuentran en clases de dominio, y ahí se producen algunos otros problemillas que trataré en el siguiente post.

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.

1. Crear un proyecto Web (no importa la herramienta, son siempre iguales)
2. Configurar el web.xml indicándole que direcciones los pedidos (de alguna url) al servlet de jax-ws

<listener>
	<listener-class>
		com.sun.xml.ws.transport.http.servlet.WSServletContextListener
	</listener-class>
</listener>
<servlet>
	<description>## descripción del Servlet ##</description>
	<display-name>## nombre a mostrar entre los servicios ejecutándose en el servidor ##</display-name>
	<servlet-name>## nombre de referencia dentro del xml para el Servlet ##</servlet-name>
	<servlet-class>
		com.sun.xml.ws.transport.http.servlet.WSServlet
	</servlet-class>
	<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
	<servlet-name>## nombre de referencia dentro del xml para el Servlet ##</servlet-name>
	<url-pattern>/##url_dentro_de_la_aplicacion_para_el_servlet##</url-pattern>
</servlet-mapping>

3. Crear un WEB-INF/sun-jaxws.xml que contenga:

<?xml version="1.0" encoding="UTF-8"?>
<endpoints xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime' version='2.0'>
	<endpoint name='##nombre_de_la_aplicacion##' implementation='paquete.ClaseConAnotacionWebService' url-pattern='/url_asignada_al_servlet_del_webservice' />
</endpoints>

4. Configurar las clases que se desea publicar como WebService, con un @WebService
5. Descargar el jax-ws (la descarga es un jar, que al clickear muestra una licencia y al aceptar descomprime muchos archivos). Hay que copiar todos los *.jar dentro del directorio $CATALINA/lib
6. Al desplegar la aplicación web, dentro de un WAR, en el tomcat, el jax generará automáticamente los wsdl y todo archivo necesario para publicar el webservice.

Espero que con esto se entienda, links de referencia:

• http://mywheel.net/blog/index.php/2007/04/18/deploying-java-6-web-services-in-tomcat/
• http://mywheel.net/blog/index.php/2007/03/28/web-services-in-java-6/

El problema estaba en el Oracle Client que estabamos usando, nos habiamos instalado el InstantClient de Oracle de 64 bits y si bien lo estabamos haciendo sobre Windows 7 de 64 bits, el problema de que la conexión entre Toad y el Client era fallida se debía a que por alguna razón Toad for Oracle 10 es compatible solo con InstantClient de 32 bits.

A continuación paso a detallar los pasos que seguimos para hacer que la conexión sea exitosa:

- En primero creamos una carpeta con el nombre “oracle” en el C:\.  Allí creamos dos carpetas mas, una con el nombre “bin” y la otra “network”.

- Una vez hecho esto lo que hicimos fue crear, en la carpeta “network”, la carpeta “admin” (tal como se muestra en la imagen anterior) y dentro de esta última los siguientes archivos: tnsnames.ora y sqlnet.ora.

Ahora les paso el detalle del contenido de cada archivo:

tnsnames.ora

XE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.33.7)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XE)
    )
  )

EXTPROC_CONNECTION_DATA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
    )
    (CONNECT_DATA =
      (SID = PLSExtProc)
      (PRESENTATION = RO)
    )
  )

ORACLR_CONNECTION_DATA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
    )
    (CONNECT_DATA =
      (SID = CLRExtProc)
      (PRESENTATION = RO)
    )
  )

————

sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES = (NTS)

———–

- Por último, lo que nos quedó por hacer fue agregar las variables de entorno que les detallo a continuación:

• ORACLE_HOME = C:\oracle
• ORACLE_HOME_NAME = C:\oracle
• SQL_PATH = C:\oracle
• TNS_ADMIN = C:\oracle\network\admin
• LD_LIBRARY_PATH = C:\oracle\bin

Y luego agregamos en el PATH:

• C:\oracle\bin

Bueno, una vez hecho todo esto la conexión fue un rotundo éxito.

Aquí les dejo el la URL de donde sacamos la info para poder seguir todos los pasos detallados antes, tambiés les paso el link para la descarga del InstantClient 32 Bits.

- Blog XP-RIENCE

- IstantClient (descargar el archivo: instantclient-basiclite-win32-11.2.0.1.0.zip)

Esta fué mi primer publicación, espero que les sirva y se entienda, ante cualquier reclamo comunicarse con defensa al consumidor.

Saludos!!

Fernando M. S. Garrido.-

Esta acción nos pone más cerca de la calidad que queremos y sabemos nos da ventaja competitiva en el mercado de software.

Hemos de confesar que la Guía 90003, creada por la ISO/IEC avalada por IRAM que aunque parece estar orientada al software también está un poco desactualizada dando valor y haciendo requerimientos que van en contra de algunas de nuestras filosofías: ser ágiles. Uno de los auditores no podía entender nuestra dinámica… si, somos raros, ¿y qué? (Gracias Ana por la paciencia)

Este proyecto se inicio a partir de un subsidio de tipo ANR (aporte no retribuible) de la Agencia Nacional de Promoción, Ciencia y Tecnología. Que brinda el 50% del costo total del proyecto sin necesidad de devolverlo. Subsidio que, además, aprovechan muchas empresas de software.

La certificación de calidad también nos permite entrar dentro del marco de la ley de promoción de la industria de software. Permitiéndonos mantener nuestros precios competitivos a la par de nuestro crecimiento.

Fue un día largo, todos terminamos agotados pero afortunadamente se creó un excelente clima con los auditores, asesores y todo el equipo de la empresa quienes hicieron de eslabón esencial para llegar a este logro. Estamos orgullosos de haber dado este paso y nos entusiasma el futuro. Pero, principalmente, estamos muy contentos.

Aquí algunas fotos celebrando el momento al final del día. (Habíamos guardado un Champagne por si todo salía bien… y salió tan bien que también abrimos la sidra que estaba en la heladera)

• 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

Aquí un interesante link donde explica las vicisitudes de usar imágenes en WordPress… Espero les sirva.

pd: Si, es un post corto y apunta a uno de los archivos de documentación de WordPress… pero, no por eso, menos interesante!