Hoy voy a hablar de una herramienta que debería ser de uso común para el desarrollo. Estoy hablando de JUnit, la librería de pruebas unitarias más utilizado en entornos Java.

Las pruebas unitarias consisten en desarrollar código para probar una determinada funcionalidad de nuestra aplicación.

Vamos a ver un pequeño ejemplo. Supongamos que estamos haciendo una librería matemática que incluye una funcion para calcular el factorial de un número. Podría ser una clase parecida a la siguiente:

package org.tcymu.util;

public class MathLibrary {
	public static int factorial(int n) throws IllegalArgumentException {
		int response = 1;

		if (n < 0) {
			throw new IllegalArgumentException();
		}

		if (n > 0) {
			response = n * factorial(n - 1);
		}

		return response;
	}
}

En esta entrada voy a utilizar las facilidades que da Eclipse gracias a su integración con JUnit. Para ello en la vista package sobre la clase que queremos probar hacemos botón dereco -> “New” -> “JUnit Test Case”.

Nos aparece la siguiente ventana en la que seleccionamos “New JUnit 4 test” (tened en cuenta que JUnit 4 necesita Java 1.5 o superior).

Podemos ver que nos propone un nombre para la clase de pruebas, así como un paquete y una carpeta de fuentes (por defecto propone el mismo paquete que las fuentes, aunque podríamos elegir otro). También podemos seleccionar que nos cree los siguientes métodos de apoyo para preparar el entorno de los test o liberar recursos:

- Métodos setUp y tearDown. Los ejecuta antes de llamar a cada método de prueba en esa clase. La secuencia sería setUp, metodo1Test, tearDown, setUp, metodo2Test, tearDown.

- Métodos setUpBeforeClass y tearDownAfterClass. Estos métodos se ejecutan antes y después de todos los métodos de la clase. La secuencia sería setUpBeforeClass, metodo1Test, metodo2Test, tearDownAfterClass.

A continuación nos pide los métodos que queremos probar. En este ejemplo seleccionamos el método que queremos probar (factorial) y ninguno de los métodos de apoyo (en nuestro sencillo ejemplo no necesitamos crear ni liberar nada).

Tras finalizar y si no tenemos la librería JUnit 4 en el Build Path nos la añade. Y por último crea el esqueleto de la clase de prueba:

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		fail("Not yet implemented");
	}

}

Hay que destacar que lo que realmente convierte al método en un test que ejecutará JUnit es la anotación Java @Test, al igual que lo que marcaría a los métodos de apoyo serían anotaciones como @BeforeClass, @AfterClass, @Before y @After.

Podemos observar que el método testFactorial sólo contiene la línea fail("Not yet implemented"); , por lo que si ejecutamos el test (mediante botón derecho sobre la clase de pruebas y “Run As” -> “JUnit Test” se nos abre la vista de JUnit con el siguiente resultado:

Por tanto es hora de implementar nuestra prueba para pasar la barra al ansiado color verde. Básicamente se hacen comprobaciones de los resultados esperados frente a los recibidos mediante la clase org.junit.Assert (documentación Javadoc de JUnit).

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Assert;
import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		Assert.assertEquals(1, MathLibrary.factorial(0));
		Assert.assertTrue(1 == MathLibrary.factorial(1));
		Assert.assertEquals(24, MathLibrary.factorial(4));
		Assert.assertEquals(720, MathLibrary.factorial(6));

		boolean excepcionLanzada = false;
		try {
			MathLibrary.factorial(-1);
		} catch (IllegalArgumentException e) {
			excepcionLanzada = true;
		}
		Assert.assertTrue(excepcionLanzada);
	}

}

Vemos que utilizamos varios métodos para comprobar que se obtiene el resultado esperado. También podemos ver cómo probamos que se lanza la excepción esperada cuando el argumento no es válido (creo haber leído en algún sitio que se iba a mejorar la prueba de excepciones en próximas versiones, pero no consigo localizar la noticia).

Una vez que se ejecutan la prueba con éxito (la barrita verde) sabemos que el método funciona como nosotros esperamos. Ahora tras cualquier cambio en el código volveríamos a ejecutar JUnit para comprobar que no hemos roto nada. Esto nos da una gran seguridad a la hora de meter mano o refactorizar métodos complejos.

Por último no quisiera terminar la entrada sin nombrar un par de temas relacionados con las pruebas unitarias.

- Una buena prueba debe ser repetible (se debe de poder lanzar cuantas veces queramos sin afectar a nada). Por ello cada vez más se automatizan las pruebas en los procesos de integración continua de forma que antes de generarse una versión de una aplicación se corren todas las pruebas para dicha aplicación.

- Existe un modelo de desarrollo que promueve que primero se escriban las pruebas y después el código. Es el llamado Desarrollo Guiado por Pruebas o Test Driven Development (TDD).

Espero que os haya gustado esta pequeña introducción.

Git es un sistema de control de versiones al igual que CVS, Subversion y otros.

Git fue diseñado por Linus Torwalds (creador de Linux) para utilizarlo en el desarrollo del núcleo de Linux. En su sección de descargas podemos encontrar entre otras, enlaces a versiones para Linux (en rpm o deb), MacOS y Windows (a través de Cygwin o del proyecto MSysGit que provee instalables completos e incluso una versión portable).

Si venimos desde un enfoque más clásico como CVS o Subversion, la principal diferencia que aporta Git es que es un sistema distribuido. ¿Y qué quiere decir distribuido?. Pues que a diferencia de CVS o Subversion podemos trabajar con nuestro control de versiones aunque no estemos conectados a una red, ya que es como si tuviésemos el servidor en nuestra propia máquina. De esta forma está diferenciado lo que son las acciones con nuestro repositorio y las que llevamos cabo con repositorios remotos (ese sería el estilo CVS).

En principio es una solución muy recomendable si queremos mantener un versionado en nuestra máquina de desarrollo (en este caso sólo utilizaremos los comandos entre desarrollo y el repositorio propio del esquema. Vamos a ver un pequeño resumen de los comandos que utilizaríamos en este caso.

• Lo primero que necesitamos es configurar nuestro usuario:

  git config --global user.name "Don Nadie"
git config --global user.email "don.nadie@test.com"

• Para crear un repositorio nos situaremos en el directorio principal de nuestro proyecto (o en uno vacío si es un proyecto nuevo) y haremos:

  git init

  y si el proyecto está empezado añadiremos los archivos mediante

  git add .
git commit -m "Mensaje" (Si no se le pasa -m nos pedirá un mensaje, ya que es obligatorio)

  con lo que ya tendremos todo nuestro proyecto bajo el control de versiones.

• Para el ciclo de desarrollo normal, primero se añaden los cambios al índice (es como un almacén intermedio que almacena todos los cambios) y luego lo persistiremos en el repositorio.

  git add ruta/fichero Añade el fichero nuevo o modificado al índice
  git commit Persiste los cambios que tenemos en el índice al repositorio (nos pide mensaje)
  git commit -a Hace el paso al índice y el commit en un solo paso

• Para ver el estado del desarrollo podemos utilizar los siguientes comandos:

  git status Muestra el estado de la rama de desarrollo
  git diff Muestra las diferencias entre la rama de desarrollo y el índice
  git diff --cached Muestra las diferencias entre el índice y el HEAD (último commit)
  git diff HEAD Muestra las diferencias entre la rama de desarrollo y el HEAD
  git log Nos muestra un historial de los commits del repositorio

• El trabajo con ramas es muy sencillo en Git.

  git branch test Crea una rama de nombre “test” a partir de la actual
  git branch Nos muestra las ramas existentes y la rama en la que nos encontramos (cuando hacemos git status también nos muestra la rama en la que nos encontramos)
  git checkout test Nos sitúa en la rama test
  git merge test Si nos hemos situado en la rama master (la rama principal, en la que empezamos) nos combina los cambios en la rama test con esta rama

Git también tiene gran potencia para compartir el código con otros desarrolladores, aunque este caso lo dejaremos para otra entrada.

Por último no quisiera terminar esta entrada sin decir que Git no es el único control de versiones distribuido. También Mercurial o Bazaar nos pueden servir para los mismos fines e incluso pueden ser más sencillas si estamos acostumbrados a CVS.

En esta entrada vamos a intentar explicar un poco la estructura de directorios en Linux, concretamente la que se define en el FHS (Filesystem Hierarchy Standar) que es un estándar definido por un grupo de organizaciones (entre ellas empresas como HP, Red Hat o IBM). Eso sí, luego cada distribución es un mundo, y los estándares no se siguen al 100%.

Si listamos el contenido del directorio raiz en nuestro Linux (mediante cd / nos situamos en el raiz y con ls hacemos el listado) veremos algo similar (en este caso es mi Xubuntu a lo siguiente.

Los directorios que nos encontramos son los siguientes:

• bin: Es el directorio en el que encontramos los principales ejecutables del sistema.
• sbin: Contiene ejecutables reservados al superusuario.
• boot: El directorio boot contiene los elementos necesarios para el arranque del sistema.
• dev: En Linux los dispositivos como particiones de discos duros, modems, terminales y demás se representan como un fichero. El directorio dev continene dichos elementos (devices en inglés).
• etc: Este directorio contiene la configuración de nuestro sistema.
• home: Dentro de este directorio se encuentran los directorios de los distintos usuarios del sistema. Es algo similar al Documents and Settings de los sistemas Windows.
• lib: En este directorio se encuentran librerías de uso común por distintas aplicaciones como los ejecutables de bin y sbin.
• media: En media se suelen montar los elementos no permanentes tales como memorias usb o cdroms. Este es un directorio de relativamente uso reciente, aunque yo las distribuciones que uso ya lo utilizan.
• mnt: Este directorio antiguamente se utilizaba para montar casi todo. Hoy en días según el FHS se debe utilizar para montajes temporales por parte del administrador.
• opt: En este directorio se debería instalar el software de terceras partes. Sería algo similar al “Archivos de Programa” o “Program Files” de Windows.
• proc: Este es un directorio virtual en el que el núcleo y otros procesos muestran su estado. Por ejemplo el archivo uptime mantiene el tiempo que lleva en funcionamiento el sistema.
• root: Es el directorio personal del superusuario.
• srv: En srv según el estandar se deberían situar los ficheros que sirve nuestro sistema (a través de un servidor web o ftp por ejemplo). Sin embargo no está demasiado difundido su uso.
• sys: Otro directorio virtual que es utilizado por los elementos conectados al sistema, como los elementos Plug and Play.
• tmp: Es el directorio de uso temporal del sistema.
• usr: Este directorio es toda una estructura de directorios estáticos (no varían) que contiene tanto software como otros recursos. Podría ser compartido entre varios sistemas.
• var: Otra gran estructura de directorios, aunque contrariamente a usr, la información que se almacena en var es variable, como por ejemplo los logs del sistema.

Como podemos ver, no es una estructura sencilla ni especialmente intuitiva, por lo que no es de extrañar que algunas distribuciones como por ejemplo Gobolinux utilicen una estructura completamente diferente.

iBatis es un framework de persistencia para Java, aunque con bastantes diferencias respecto a Hibernate, el gran dominador en este segmento.

La principal diferencia entre iBatis e Hibernate es que iBatis no es un ORM (Mapeo Objeto Relacional). Por lo tanto Hibernate genera el SQL para mapear objetos a tablas de la base de datos, mientras que en iBatis el SQL lo tendremos que escribir nosotros. Si tenemos un modelo de datos (nuestras tablas de BBDD) bastante diferente a nuestro modelo de negocio (nuestras clases Java) Hibernate nos puede dar bastantes dolores de cabeza.

Lo que sí hace iBatis es lo siguiente:

• Ejecuta el SQL escrito por nosotros mediante JDBC[] (Java DataBase Connectivity), por lo que nos olvidamos de los múltiples try/catch.
• Mapea propiedades de objetos a parámetros para las PreparedStatement (sentencias SQL parametrizables).
• Mapea los resultados de una query a un objeto o una lista de objetos.

En esta entrada ahora podría poner un pequeño ejemplo de utilización de iBatis, pero eso es lo que podemos encontrar en la documentación de iBatis en español.

Como resumen de lo que se puede ver en dicah documentación comentar:

• Tendremos un fichero de configuración de iBatis (SqlMapConfig.xml habitualmente) en el que indicaremos algunos parámetros de iBatis (como si está activo el cacheado), el DataSource (soporta varios tipos de DataSource) y los distintos mapeos SQL.
• Tendremos al menos un fichero de mapeo xml, en el que se indican las sentencias SQL, los parámetros a mapear o los resultados a mapear.
• Tendremos una clase que implementa SQLMapClient que es el interface que contiene los métodos para realizar las sentencias SQL (queryForObject, queryForList o delete entre otros muchos). Esta clase la habremos obtenido mediante SqlMapClientBuilder.

Otro punto fuerte de iBatis es su integración con Spring. Para trabajar con iBatis integrado en Spring los pasos a seguir serían los siguientes:

• El DataSource lo definiremos como un Bean en los archivos de definición de Spring. El resto del SqlMapConfig.xml y los xml de mapeo seguirían igual.
• Spring proporciona el SqlMapClientFactoryBean y SqlMapClientTemplate. A la factoría le proporcionaremos el DataSource y al template le proporcionamos la factoría. Ese template es la clase que nos proporciona los mismo métodos que el SQLMapClient visto anteriormente.

También quiero nomrar en esta entrada a Ibator, que es una herramienta para generar código para iBatis. A partir de una tabla de base de datos es capaz de generar el xml de mapeo, las clases Java que representan al modelo de datos e incluso los DAO (Objetos de Acceso a Datos). Viene incluido un plugin para Eclipse. Aunque no la he utilizado, puede ser una herramienta útil en ocasiones.

Y por último decir que aunque sólo he hablado de iBatis para Java, desde la página del proyecto nos podemos descargar versiones para .Net o Ruby.

Hace poco hemos visto cómo utilizar AJAX en un formulario con CakePHP y hemos hablado en varias ocasiones de jQuery. Ahora vamos a ver cómo utilizar jQuery a través de CakePHP.

Dean Sofer comenta en Serving up actions as AJAX with jQuery in a few simple steps ( en inglés) que él no cree necesario un helper AJAX para jQuery (recordemos que el helper AJAX de CakePHP utiliza script.aculo.us) ya que un helper se utiliza para crear HTML y el javaScript debería estar lo más separado del HTML como sea posible (separación de funciones).

En este ejemplo vamos a modificar el código de nuestra aplicación de gestión de enlaces tal y como lo dejamos tras utilizar el formulario AJAX para insertar nuevos enlaces. Quitaremos todas las referencias al Helper de AJAX y le daremos la misma funcionalidad mediante jQuery.

Vamos a ver primero el controlador, explicando los cambios.

<?php
class LinksController extends AppController {

	var $name = 'Links';
	var $helpers = array('Html', 'Form', 'Javascript');
	var $components = array('RequestHandler');

	function add() {
		if (!empty($this->data)) {
			if ($this->Link->save($this->data)) {
				//$this->flash('Enlace añadido.','/links',3);
			}
		}
		$this->set('links', $this->Link->findAll());
		//$this->render('index', 'ajax');
		$this->render('list');
	}

	function index() {
		$this->set('links', $this->Link->findAll());
	}

}
?>

• Eliminamos el helper de AJAX, aunque mantenemos el de JavaScript.
• Añadimos el componente RequestHandler. Este componente identifica las peticiones vía AJAX para poder responder con el layout AJAX (por defecto vacío). Como ahora sólo vamos a hacer llamadas a add() mediante AJAX podríamos omitir este componente y realizar la llamada a la vista mediante $this->render('list','ajax'); (hemos añadido el parámetro que indica el layout a utilizar).
• Hemos cambiado la vista a mostrar por list, que veremos a continuación.

Ahora vemos la vista principal (/app/views/links/index.ctp):

<?php
echo $javascript->link('jquery-1.3.1.min.js',false);
echo $javascript->link('jquery.form.js',false);
?>
<script type="text/javascript">
$(document).ready(function() {
    var options = {
        target:'#links',
		clearForm: true
    }; 

    $('#newLinkForm').ajaxForm(options);
});
</script>

<h1>Enlaces disponibles</h1>
<div id="links">
<?php echo $this->element('linksList', array('links' => $links)); ?>
</div>

<h2>Añadir enlace</h2>
<?php
echo $form->create('Link', array('action' => 'add', 'id' => 'newLinkForm'));
echo $form->input('title', array('label' => 'Nombre', 'error' => __('Titulo no valido', true)));
echo $form->input('url');
echo $form->submit('Añadir',array('escape'=>false));
echo $form->end();
?>

• Lógicamente he sustituido los links a script.aculo.us por los de jQuery. Utilizo el plugin jQuery Form Plugin que me facilita la introducción de AJAX en el formulario.
• Añado el código JavaScript prácticamente como aparece en la página de jQuery Form Plugin. En target se le indica el div en el que se va a introducir la respuesta (en este caso el que tenga id “links”). Al final le aplicamos el método ajaxForm al formulario con id “newLinkForm”.
• He sustituido todo el listado de links por una llamada a un elemento CakePHP pasándole unos datos ($this->element('linkslist', array('links' => $links));). Luego explicaré el por qué de este cambio.
• La creación del formulario la hago como inicialmente mediante el helper de formularios (ya no mediante el de AJAX). Le pongo el id como parámetro.

Vamos a ver ahora el elemento al que hacíamos referencia en la vista. Lo encontraremos en /app/views/elements/linksList.ctp.

<?php foreach ($links as $link): ?>
<p>
<a href="<?php echo $link['Link']['url']; ?>"><?php echo $link['Link']['title']; ?></a></p>
<p>Añadido: <?php echo $link['Link']['created']; ?></p>
<ul>
<?php foreach ($link['Comment'] as $comment): ?>
<li><?php echo $comment['comment'] . ' (' . $comment['created'] . ')'; ?></li>
<?php endforeach; ?>
<li><?php echo $html->link('Añadir comentario', '/comments/add/' . $link['Link']['id']);?></li>
</ul>
<?php endforeach; ?>

Como podemos ver es exactamente el mismo código que teníamos en la página principal y que generaba el listado de enlaces. Lo que hemos hecho es crear un elemento de CakePHP, es decir, una porción reutilizable. Y la reutilizamos en la página principal y en la nueva vista que hemos creado para la respuesta AJAX, que sólo tiene que contener el listado. Vemos dicha vista (/app/views/links/list.ctp) a continuación:

<?php echo $this->element('linkslist', array('links' => $links)); ?>

Y con esto ya tenemos funcionando el formulario AJAX mediante jQuery.

Pues hoy hace un año de la primera entrada que puse en mi blog, mi pequeña presentación.

Hoy un año después hago un pequeño análisis de este primer año de Tus ceros y Mis Unos.

En primer lugar, decir que estoy bastante satisfecho del camino recorrido. Me propuse crear el blog para obligarme a seguir aprendiendo, para mejorar mi visibilidad como profesional y para devolver a la comunidad parte de lo aprendido de ella. En general creo que mis expectativas al respecto se han cumplido.

En su día pensaba mantener un ritmo de una o dos entradas semanales, lo que evidentemente no he cumplido. Sin embargo he publicado 37 entradas en total (aunque 3 ó 4 de avisos o generalistas) todas de factura propia que siempre tienen más trabajo que traducir o enlazar a entradas en inglés (en si día contaba con traducir de vez en cuando).

En cuanto a datos de acceso, pues también estoy contento, ya que parece que mi esfuerzo le es útil a otras personas. Tengo un promedio entre 60 y 80 visitas diarias con un record de 161 visitas en un día y 12.987 visitas totales. No tengo ni idea sobre los datos de otros blogs de temática similar, pero para mí cumple mis expectativas.

En cuanto a temas, CakePHP y OSGi se han llevado la palma.

Para el futuro intentaré seguir el ritmo de una entrada semanal. Los temas seguirán en la línea de lo ya publicado, seguiremos ampliando algunos temas y descubriremos cosas nuevas (según se me vaya presentando).

Por último daros las gracias a todos los que visitáis tus Ceros y Mis Unos, ¡permaneced a la escucha!.

En esta nueva entrada dedicada a CakePHP voy a explicar cómo utilizar un poco de AJAX en nuestra aplicación. AJAX realiza peticiones al servidor en segundo plano, por lo que partes de la página se pueden ir refrescando sin tener que recargar la página entera.

Voy a utilizar el ejemplo del gestor de enlaces que ya tenía en marcha en anteriores entradas de CakePHP en Tus Ceros Y Mis Unos. En concreto voy a facilitar el agregar nuevos enlaces pasando el formulario de añadir enlace a la página principal, de forma que al completar dicho formulario se refresque en el listado sin recargar la página completa.

El ayudante (“helper”) de AJAX en CakePHP utiliza las librerías JavaScript script.aculo.us y Prototype. Nos descargamos la última versión estable de script.aculo.us (la 1.8.2 en el momento de escribir esta entrada) ya que incluye Prototype. Copiamos tanto el fichero de Prototype (en lib dentro de la carpeta de script.aculo.us) como todos los ficheros propios de script.aculo.us (en src) a la carpeta de JavaScript de nuestra aplicación CakePHP: /app/webroot/js.

Insertamos en la plantilla por defecto de nuestro sitio web (/app/views/layouts/default.thtml) una línea para que CakePHP sepa dónde insertar los scripts posteriormente. La línea es <?php echo $scripts_for_layout ?> al igual que teníamos <?php echo $content_for_layout ?> que indicaba dónde insertar el contenido:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
	<title>TCYMU CakePHP Gestión de Enlaces</title>
	<?php echo $scripts_for_layout ?>
</head>
<body>
	<h1>Tus ceros y mis unos</h1>
	<h2>Gestión de enlaces</h2>

	<?php echo $content_for_layout ?>

	<h3>TCYMU por Miguel Orbegozo</h3>
</body>
</html>

Ahora es el momento de modificar el controlador de nuestra aplicación. Primero enumero los cambios y luego muestro el código completo. Las modificaciones son las siguientes:

1. Definimos la variable helpers con los ayudantes que se utilizan. Si no sobrescribimos la variable se incluyen el de HTML y el de formularios. Además queremos añadir el de JavaScript y el de AJAX.
   var $helpers = array('Html', 'Form', 'Javascript', 'Ajax');
2. Modificamos la función add, ya que ahora responderá a una petición AJAX. Lo que hacemos tras insertar el contenido del formulario (exactamente igual que antes) es obtener la lista de enlaces (igual que en la función index) y mostrar la vista index, con la particularidad de que le pasamos el parámetro 'ajax' para que sepa que es una respuesta a una petición AJAX.

<?php
class LinksController extends AppController {

	var $name = 'Links';
	var $helpers = array('Html', 'Form', 'Javascript', 'Ajax');

	function add() {
		if (!empty($this->data)) {
			if ($this->Link->save($this->data)) {
				//$this->flash('Enlace añadido.','/links',3);
			}
		}
		$this->set('links', $this->Link->findAll());
		$this->render('index', 'ajax');
	}

	function index() {
		$this->set('links', $this->Link->findAll());
	}

}
?>

Ahora modificaremos la vista de nuestra página de inicio (/app/views/links/index.thtml). Como antes primero se enumeran los cambios para después ver el código en su totalidad.

1. Añado las librerías JavaScript mediante el método de AjaxHelper link.
   <?php
echo $javascript->link('prototype.js',false);
echo $javascript->link('scriptaculous.js?load=effects',false);
?>
   Dos pequeños detalles. El segundo parámetro hace que se añadan en la cabecera (en $scripts_for_layout que definimos antes). Al poner scriptaculous.js?load=effects hacemos que sólo se carguen los scripts de efectos, ya que si sólo hubiéramos puesto scriptaculous carga todos los ficheros de script.aculo.us
2. La lista de enlaces la vamos a situar en un div con un identificador determinado, ya que esta será la parte que se refresque tras la petición AJAX. Lo creamos mediante el ayudante de AJAX y sus métodos div y divEnd.
   <?php echo $ajax->div('links'); ?>
...
<?php echo $ajax->divEnd('links'); ?>
3. Sustituimos el enlace que nos llevaba a la página de añadir enlace por el formulario que aparecía en esta página.
4. Sustituimos la creación del formulario. En lugar de utilizar el método form del ayudante de formularios utilizaremos el método form pero del ayudante de AJAX. A este método se le pasa la función del controlador, el tipo de envío (“get” o “post”) y un array de opciones en el que en update le indicamos el div que debe refrescar.
   echo $ajax->form('/add', 'post', array('update' => 'links'));

<?php
echo $javascript->link('prototype.js',false);
echo $javascript->link('scriptaculous.js?load=effects',false);
?>

<h1>Enlaces disponibles</h1>

<?php echo $ajax->div('links'); ?>
<?php foreach ($links as $link): ?>
<p>
<a href="<?php echo $link['Link']['url']; ?>"><?php echo $link['Link']['title']; ?></a></p>
<p>Añadido: <?php echo $link['Link']['created']; ?></p>
<ul>
<?php foreach ($link['Comment'] as $comment): ?>
<li><?php echo $comment['comment'] . ' (' . $comment['created'] . ')'; ?></li>
<?php endforeach; ?>
<li><?php echo $html->link('Añadir comentario', '/comments/add/' . $link['Link']['id']);?></li>
</ul>
<?php endforeach; ?>
<?php echo $ajax->divEnd('links'); ?>

<h2>Añadir enlace</h2>
<?php
echo $ajax->form('/add', 'post', array('update' => 'links'));
echo $form->input('title', array('label' => 'Nombre', 'error' => __('Titulo no valido', true)));
echo $form->input('url');
echo $form->submit('Añadir',array('escape'=>false));
echo $form->end();
?>

Con estos cambios ya se actualizará nuestra lista de enlaces tras rellenar el formulario y sin recargar la página. Misión cumplida.

Mi hijo (4 años) tiene un usuario (¡se sabe su contraseña y todo!) en el Ubuntu que tengo en casa. Le tengo puesto un fondo de escritorio de su gusto y sabe lanzar GCompriss que es la única aplicación que utiliza. De momento eso es todo, pero él se lo pasa muy bien cuando se pone.

El caso es que como ese Ubuntu es en cierto modo experimental (al menos hasta que consiga desbancar a openSUSE en mis preferencias) estaba buscando una distribución completa para dejarla de manera más estable en una partición pequeña. Y ya puestos lo mejor era buscar una distribución orientada a niños. Aquí os presento un pequeño resumen de mi búsqueda. Las distribuciones con este perfil que he encontrado son:

• Edubuntu: Amparada por la todopoderosa Ubuntu. Incluye GCompriss y el paquete educativo de KDE (que también tiene muy buena pinta) entre otras (ver lista de aplicaciones). Su instalación parte de un Ubuntu desktop instalado ya que lo que descargaremos será una serie de paquetes y no un sistema entero. Tiene soporte para instalación en un entorno educativo con un servidor y clientes ligeros (LTSP).
• Foresight Kid’s Edition: Subproyecto de Foresight, una distribución basada en el administrador de paquetes Conary. No falta GCompriss. En el siguiente enlace podemos ver un análisis de Foresight Kid’s Edition ( en inglés).
• Qimo for kids: Una reciente distribución que se basa también en Ubuntu. Como dicen en su web, se diferencian de Edubuntu en que se instala directamente (no necesita un Ubuntu instalado) y que no busca el soporte de entorno con clientes ligeros.



• ZenEdu Live: Está en pausa según su web y por tanto no lo considero una opción.
• Debian Jr.: Es lo que llaman una mezcla de Debian (Debian Pure Blend), es decir un empaquetado especial de Debian dirigido a un sector específico (en este caso los niños). Está en desarrollo pero todavía no tienen imágenes finales por lo que no lo considero todavía una opción.

Como vemos, al final tenemos tres distribuciones a probar. Edubuntu, Qimo y Foresight Kid’s, aunque las pruebas quedarían para una segunda entrada. Si alguien conoce alguna otra distribución que incluir en la lista que me lo haga saber por favor.

En la anterior entrada sobre Terracotta pusimos un pequeño ejemplo con un servidor y tres clientes (un productor de tareas y dos consumidores), aunque todo corriendo en la misma máquina. Además también dejamos el ejemplo dando un feo aviso porque todos los clientes intentaba utilizar el mismo archivo de log.

En esta pequeña continuación vamos a utilizar el mismo ejemplo pero lo iremos mejorando, primero eliminando el aviso de los logs y después utilizando varias máquinas.

Para llevar a cabo esta tarea vamos a utilizar un único tc-config.xml, que lo cargará el servidor y los clientes lo tomarán de él. Para ello es necesario arrancar el servidor (start-tc-server) desde el directorio en el que tenemos el tc-config.xml o mediante la opción -f:

start-tc-server.bat -f /ruta/al/fichero/tc-config.xml (será .bat o .sh según estemos en Windows o Unix)

Pero antes vamos a hacer unos cambios en el archivo de configuración. Le vamos a añadir la lista de servidores y le vamos a configurar el directorio de logs en función de una variable de entorno. En la web de Terracotta tenemos una guía y referencia de la configuración en la que podemos ver las descripciones de esos campos y muchos otros.

<?xml version="1.0" encoding="UTF-8"?>
<tc:tc-config xmlns:tc="http://www.terracotta.org/config">
  <servers>
    <server host="169.254.122.220"/>
  </servers>
  <clients>
    <logs>logs-%(tcymu_name)</logs>
  </clients>
  <application>
    <dso>
      <roots>
        <root>
          <field-name>org.tcymu.terracotta.TasksQueue.queue</field-name>
        </root>
      </roots>
      <instrumented-classes>
        <include><class-expression>org.tcymu.terracotta.Task</class-expression></include>
      </instrumented-classes>
    </dso>
  </application>
</tc:tc-config>

Como vemos hemos añadido la sección de servidores y la de clientes. En la de servidores ponemos la dirección IP de nuestro único servidor. En la parte de clientes configuramos el nombre del fichero de logs en función de la variable de entorno tcymu_name.

Ya podemos arrancar el servidor como hemos visto un poco más arriba. También arrancamos el generador de tareas con el comando mostrado a continuación:

dso-java.bat -Dtc.config=169.254.122.220:9510 -Dtcymu_name=creator -cp classes org.tcymu.terracotta.TaskCreator

Las diferencias con respecto al que utilizamos en la primera parte son:

• Se le pasa la dirección del servidor (con su puerto por defecto en este caso) de la que va a tomar el tc.config.xml.
• Se le pasa la variable de entorno que se utiliza para nombrar el archivo de logs.

Utilizaremos un comando similar para arrancar el primero de los consumidores de tareas, variando sólo la clase a arrancar y el valor de la variable de entorno para el fichero de logs.

Por supuesto al tomar el tc.config.xml de un servidor a través de una dirección IP podemos arrancar el segundo consumidor en otra máquina (en este caso un openSUSE virtualizado sobre VirtualBox):

dso-java.sh -Dtc.config=169.254.122.220:9510 -Dtcymu_name=resolver2 -cp classes org.tcymu.terracotta.TaskResolver

Con esto terminamos esta pequeña continuación.

En esta entrada voy a presentaros Terracotta. Terracotta se distribuye bajo una doble licencia libre-comercial. Terracotta es una herramienta de cluster a nivel de máquina virtual Java (JVM) o como dicen en su web una memoria distribuida en red o NAM (Network Attached Memory por similitud con Network Attached Storage). Esto quiere decir que podemos compartir objetos o parámetros de objetos entre distintas máquinas virtuales Java, incluso corriendo en distintas máquinas. Esto se logra mediante una arquitectura cliente-servidor (transparente a nuestra aplicación) por un lado y un cargador de clases (ClassLoader) especial. Terracotta también permite “clusterizar” ese servidor que hemos nombrado para entornos de alta disponibilidad. Señalar también que Terracotta no utiliza la serialización Java si no un intercambio de los parámetros que se modifican en cada caso, de forma que se minimice el tráfico en la red. Tras esta pequeña introducción teórica vamos a ver un pequeño ejemplo. Creamos una pequeña clase que representa una tarea a realizar por nuestra aplicación:

package org.tcymu.terracotta;

public class Task {
	private long duration;
	private long id;

	public Task(long id, long duration) {
		this.id = id;
		this.duration = duration;
		System.out.println("Nueva tarea " + id + " de duracion " + duration);
	}

	public void run() {
		System.out.println("Iniciando tarea " + id + " de duracion " + duration);
		try {
			Thread.sleep(duration);
		} catch (Exception e) {}
		System.out.println("Finalizando tarea " + id);
	}

}

y una que representa la cola con las tareas que hay que realizar:

package org.tcymu.terracotta;

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class TasksQueue {
	private static TasksQueue instance;
	private BlockingQueue queue = new LinkedBlockingQueue(5);

	public static TasksQueue getInstance() {
		if (instance == null) {
			instance = new TasksQueue();
		}
		return instance;
	}

	private TasksQueue() {
	}

	public BlockingQueue getQueue() {
		return queue;
	}
}

Finalmente, creamos otras dos clases, una crea tareas y otra las resuelve:

package org.tcymu.terracotta;

import java.util.Random;

public class TaskCreator {
	private static long id = 1;

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Random random = new Random();
		TasksQueue tasksQueue = TasksQueue.getInstance();
		tasksQueue.getQueue().clear();
		while (true) {
			//Duracion aleatoria 1 a 10 segundos
			long duraction = (random.nextInt(10) + 1) * 1000;
			try {
				tasksQueue.getQueue().put(new Task(id++, duraction));
				Thread.sleep(3000); //Una tarea cada 3 segundos
			} catch (InterruptedException e) {}
		}
	}
}

package org.tcymu.terracotta;

public class TaskResolver {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		TasksQueue tasksQueue = TasksQueue.getInstance();
		while (true) {
			try {
				Task task = tasksQueue.getQueue().take();
				task.run();
			} catch (InterruptedException e) {}
		}
	}
}

Como podemos ver, son clases normales, sin nada especial que resaltar. Eso sí, si ejecutamos el creador de tareas o el consumidor, lógicamente vemos que no se relacionan entre ellas. Las vamos a relacionar mediante Terracotta, y el vínculo entre ellas será la cola que es el elemento común.

Lo primero que necesitamos es descargarnos la edición libre (ES) desde la sección de descargas de Terracotta. Yo he utilizado la versión ES 2.7.3. Aparte de eso, lo único que he hecho es añadir el directorio bin de Terracotta al path para poder utilizar sus comandos más cómodamente. Como hemos dicho, Terracotta necesita un servidor y es el momento de arrancarlo. Para ello abrimos una consola y ejecutamos el script start-tc-server (está en el directorio bin que hemos añadido al path y existe en versión windows y versión unix/linux).

Ahora creamos el archivo de configuración que le indica a Terracotta cuáles son los que se guardan en la memoria de red. El fichero lo llamo tc-config.xml y lo voy a poner en el raíz  de mi proyecto Eclipse, aunque podría ir en cualquier sitio:

<?xml version="1.0" encoding="UTF-8"?>
<tc:tc-config xmlns:tc="http://www.terracotta.org/config">
  <application>
    <dso>
      <roots>
        <root>
          <field-name>org.tcymu.terracotta.TasksQueue.queue</field-name>
        </root>
      </roots>
      <instrumented-classes>
        <include><class-expression>org.tcymu.terracotta.Task</class-expression></include>
      </instrumented-classes>
    </dso>
  </application>
</tc:tc-config>

Primero le indicamos el objeto raíz que forma el cluster (cualquier cosa que se obtenga a partir de ese objeto también forma parte del cluster). También le indicamos las clases que Terracotta tiene que controlar (instrumented-classes), la clase Task al formar parte del cluster debe ser instrumentalizada. Para arrancar el creador de tareas ejecuto el siguiente comando en una consola situada en el raíz del proyecto:

dso-java -cp classes org.tcymu.terracotta.TaskCreator

El comando dso-java es un comando de Terracotta que tras preparar el entorno para la ejecución en cluster llama al comando java de manera normal. Por eso con esa línea estamos fijando el classpath (a classes en este caso) y ejecutando la clase TaskCreator.

Hay que señalar que dso-java (y también  start-tc-server) toman el fichero tc-config.xml del directorio desde el que se llama (aunque hay otras opciones de trabajar con los ficheros de configuración de Terracotta). Por eso ejecuto el comando lo he ejecutado en el raíz del proyecto donde está el tc-config y el directorio classes con la compilación de las clases que hace Eclipse. Sin embargo el servidor lo he ejecutado desde cualquier consola, de forma que arranca sin tomar ese tc-config. El resultado de la ejecución en el que podemos ver cómo se crean tareas es:

Y ahora arrancamos el consumidor de tareas, también desde una consola situada en el raíz del proyecto. Utilizamos el siguiente comando:

dso-java -cp classes org.tcymu.terracotta.TaskResolver

Podemos ver que lo único que cambia es la clase a ejecutar. Nos aparece un aviso respecto a que el archivo de logs está en uso, lo que se debe a que hemos arrancado varios nodos en la misma máquina. De momento no me preocupo por ello.  Nuestro consumidor empieza a resolver tareas, aunque muy probablemente no a una velocidad suficiente. Es el momento de escalar nuestra aplicación y arrancar un segundo consumidor. Abrimos otra consola nuevamente en el directorio raíz y volvemos a ejecutar el comando de arranque del consumidor. Ahora vemos que los consumidores van resolviendo tareas simultáneamente, lo que sin duda es una forma bastante fácil de escalar.

Con esto termino este pequeño ejemplo que no pretende nada más que mostrar las bondades de Terraccotta con un ejemplo funciona. Más adelante ya lo complicaremos.