Archivo de Mayo 2006

Ajax: una definición sencilla

Mayo 24, 2006

Llevo tiempo escuchando la palabra "Ajax" en infinidad de conversaciones y en múltiples páginas técnicas, pero no es fácil encontrar una buena definición en castellano de qué es, para qué sirve y cuándo usarlo.

Lo primero que hay que tener claro es que el término Ajax se está convirtiendo en una de esas palabras que hay que usar porque sino parece que no estás a la moda. Grave error. La tecnología no se lleva bien con las modas. Si es útil, se usa, sino no. Y recordemos que no hay una herramienta o tecnología mágica que lo resuelve todo.

¿Qué es Ajax?

Ajax es el nombre que recibe el proceso de utilizar un objeto JavaScript para intercambiar información en formato XML con el servidor sin tener que hacer submit de un formulario o poner una URL en el navegador: el famoso XmlHttpRequest. Eso es todo, no tiene más. Básicamente, mediante programación JavaScript se puede crear un objeto de tipo XmlHttpRequest que realice una petición a una URL determinada y encapsule el resultado en un arbol XML. Nota: en el caso de Internet Explorer, el objeto en cuestión se llama XMLHTTP.

¿Cómo funciona?

Para poder utilizar esta técnica, es necesario contar con:

  • Un navegador que soporte XMLHTTP o XmlHttpRequest.
  • Un servidor que sea capaz de responder peticiones HTTP en formato XML.

En general, esta combinación siempre está disponible gracias a que los navegadores más importantes soportan esta tecnología y los servidores HTTP suelen permitir cualquier tipo de lenguaje de la familia SML.

¿Cómo lanzar una petición Ajax?

Para ejecutar una petición Ajax, hace falta crear el objeto JavaScript correspondiente:

if (window.XMLHttpRequest) {
   req = new XMLHttpRequest();
}
else if (window.ActiveXObject) {
   req = new
ActiveXObject("Microsoft.XMLHTTP");
}

Este extracto de código creará el objeto que utilizaremos para lanzar las peticiones. Vale para todos los navegadores. Ahora habría que decirle qué URL ejecutar y abrir la conexión:

req.open("GET", url, true);

El primer parámetro es el tipo de petición: GET ó POST, el segundo parámetro es la URL y el tercer parámetro indica si debe ser una conexión asíncrona (true) o síncrona (false). En Ajax, las conexiones son asíncronas (la "A" de Ajax es "Asynchronous"). Cuidado al poner false, porque el navegador se quedará bloqueado hasta que esta conexión finalice.

El próximo paso es asignar un valor a la propiedad onreadystatechange. Esta propiedad registra una función Javascript que se ejecutará cuando la conexión finalice.

req.onreadystatechange = processXMLResponse;

También se pueden establecer cookies fácilmente:

req.setRequestHeader("Cookie", "someKey=true");

Una vez que el objeto está inicializado y listo para trabajar, lanzaremos la petición:

req.send(null);

El null vale para peticiones de tipo GET. En el caso de POST, se debe especificar los parámetros, por ejemplo:

req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded";
req.send("name=scott&email=stiger@foocorp.com");

Es aconsejable que la función que procesa el XML resultante tenga un control mínimo del resultado. El readystate 4 significa que la petición ha finalizado por completo y el status 200 es el OK del protocolo HTTP.

function processXMLResponse() {
  if (req.readyState == 4) {
    if (req.status == 200) {
     // Process the XML response
    }
  }
}

Para procesar la respuesta XML simplemente hay que utilizar las funciones de JavaScript DOM. Por ejemplo, para extraer el nombre del empleado del siguiente XML:

<employee>
  Chris
</employee>

Se puede utilizar lo siguiente:

var name = req.responseXML.getElementsByTagName("employee")[0];

Lógicamente, lo normal es recorrer árboles DOM un poco más complejos, utilizando por ejemplo bucles como el siguiente:

for (i=0;i<elements.length;i++) {
  for (j=0;j<elements[i].childNodes.length;j++) {
    var ElementData = elements[i].childNodes[j].firstChild.nodeValue;
  }
}

Y eso es todo. Espero que haya quedado claro cómo funciona Ajax de forma sencilla. Más adelante publicaré un ejemplo real de esta tecnología.

Integración contínua

Mayo 8, 2006

Suelo leer los artículos que escribe Martin Fowler. La primera vez que leí algo suyo fue su libro sobre UML, que siempre recomiendo cuando me preguntan qué leer en esa materia. Me gustó su forma de explicar temas técnicos y su opinión pragmática sobre el mundo de la informática.

En este caso voy a hacer referencia a la última versión sobre el artículo de Integración Contínua que redactó hace ya bastante tiempo. Es un documento que reune una serie de buenas prácticas ya conocidas, pero que juntas forman la mencionada integración contínua. Yo empecé a tener contacto con éstas prácticas a finales del 99, cuando tuve oportunidad de trabajar en una verdadera factoría de software.

La esencia de esta práctica, una de las 12 originales del proceso Extreme Programming, es la de que cada desarrollador realice integraciones periódicas de su trabajo, al menos una vez al día, con un repositorio de código compartido. Como señala el autor del artículo, mucha gente cree que es un trabajo imposible de lograr y que realmente no aporta mucho: dos errores muy graves. Es muy sencillo de poner en marcha, con las herramientas de hoy en día es casi inmediato, y los beneficios son enormes. Detectar problemas de integración rápidamente ayuda a que el propio proceso de integración sea más rápido ya que los problemas no aparecen de a miles y que el código sea más estable. Como consecuencia de ello, también se acelera el proceso de pruebas.

El artículo propone las siguientes prácticas como parte de la Integración Contínua:

  • Mantener un único repositorio de código
  • Automatizar el proceso de compilación y generación de ejecutables
  • Integrar pruebas automatizadas dentro del proceso de compilación
  • Todos envían su código a diario
  • Con cada cambio de código, se debería lanzar el proceso de compilación en un entorno de integración
  • Mantener el proceso de compilación rápido
  • Realizar pruebas en un entorno igual al de producción
  • Obtener la última versión de los ejecutables debe ser fácil
  • Que todos puedan ver el estado actual del código
  • Automatizar el proceso de despliegue de las aplicaciones

La lista de prácticas que propone el autor es muy completa, pero no es necesario ponerlas en marcha todas a la vez. Yo propongo plantear una introducción paulatina, dependiendo de la madurez del equipo de trabajo y de las prácticas que ya se estén aplicando, hasta completarlas todas.