Scrum Manager – En busca de la excelencia del Código
Raúl Herranz
Rev. 1.0

El texto es conciso y no muy extenso, por lo que se hace amena su lectura. Lo más importante, es que expone una serie de criterios para definir lo que se considera la excelencia del código, así como prácticas y técnicas para hacer que se consiga. El libro nos da un repaso a temas tan interesantes como la automatización de tareas, con lecciones tan importantes como la colectivización del código; pasando por las revisiones de código, la programación por parejas y revisiones por pares; las pruebas: unitarias, de integración, de sistema, de implantación, de aceptación e incluso regresión; y por último, pero no por ello menos importante, la refactorización, esa tarea siempre olvidada y que nos ahorra a la larga mucha deuda técnica.

Me gusta el formato del documento y su narrativa. Lo que quizá cambiaría es que está muy focalizado en sus ejemplos a entornos de desarrollo Java. Los pondría más genéricos y/o orientados a diferentes lenguajes y entornos de desarrollo.

En conclusión, un buen documento que nos permite hacer repaso de las técnicas que ya aplicamos y las que aún no hacemos para poder mejorar nuestro quehacer diario con buenas prácticas, buena metodología y buenos consejos. Gracias Raúl por este material, y sobretodo por poder disponer de él de forma libre y gratuita.

Teniendo en cuenta que lo que indica el libro es un pseudocódigo, es peor aún, puesto que quien lo escribe está seguro de hacerlo bien, y no dudo que incluso lo haya comprobado, pero claro, nos encontramos con que, como no es un lenguaje concreto, pueda ser una interpretación de una implementación, para la cual, se ha podido perder algo de sustancia por el camino, o cometer un error tipográfico.

Pero al grano. Montículos.

¿Qué es un montículo?

Un montículo es un árbol binario balanceado que cumple con la premisa de que: ningún padre tiene un hijo mayor (montículo de máximos) o menor (montículo de mínimos) a él. Una definición corta y concreta, ¿no?

Esta estructura de datos fue propuesta por Robert W. Floyd (premio Turing en 1978) para resolver el problema de la ordenación de elementos dentro de un vector, el famoso heapsort (u ordenación por montículo).

En la asignatura de Programación y Estructuras de Datos Avanzadas (en la carrera de Grado en Ingenería Informática de la UNED), se propone al inicio de la asignatura, como conocimiento de las estructuras de datos, el montículo.

El montículo, aunque conceptualmente se dibuja en forma de árbol, está implementado sobre un vector. Ya que es balanceado y binario, un nodo solo puede contener dos hijos. La formula para acceder a cada hijo, dado el índice del padre (i), sería:

hijo_izquierdo = 2i
hijo_derecho = 2i+1

El acceso al padre se realizaría con una división entera: i / 2.

¿Para qué sirve un montículo?

El montículo se emplea en lenguajes de alto y medio nivel, muchas veces sin darnos cuenta. En Java, por ejemplo, se implementa a través de la clase PriorityQueue, la cual permite, a través de un comparador, implementar la ordenación interna del montículo. En otros lenguajes puede aparecer igualmente como cola de prioridad (PriorityQueue) o como montículo (Heap).

El montículo en sí permite:

• Ordenar elementos de un vector de forma fácil y óptima, pudiendo implementar un comparador a medida.
• Búsquedas el máximos, mínimos, o cualquier otro factor a tener en cuenta en la selección de búsqueda de elementos.
• En problemas específicos de grafos como el recubrimiento mínimo de Prim o el camino más corto de Dijkstra.

Implementación del algoritmo

Me ha costado un poco decidir el lenguaje en el que implementarlo, finalmente, he optado por Ruby, ya que su código queda bastante pseudocodificado, pero igualmente habría quedado igual de bien en Python. El código sería:

class MonticuloMaximos
end

Vale, esto es lo básico, la definición de la clase. Ahora vamos a ir creando los métodos:

• inicializador (o constructor): inicializa el vector interno, de modo que en el momento de crear el montículo, este estará vacío:

      def initialize()
          @vector = []
      end

• vacio?: esta es una de las cosas que más me gusta de Ruby, que puedes poner en un método el símbolo de interrogación, con lo que queda bastante pseudocodificado lo que hace el método en sí. Pregunta si el montículo está vacío, y la respuesta será lógica: sí o no (veradero o falso):

      def vacio?()
          (@vector.length == 0)
      end

• flotar: aquí ya comenzamos con las acciones básicas de un montículo. La acción de flotar, se emplea cuando se agrega un elemento nuevo a la estructura. Lo más simple, dado que el montículo se implementa en un vector, es agregar al final del vector el elemento y flotarlo, hasta que su peso nos diga que está en el lugar indóneo, esto hace que el coste del algoritmo sea lineal, y por lo cual, óptimo:

      def flotar(i)
          padre = i / 2
          while (i>1 and @vector[padre-1]<@vector[i-1])
              @vector[i-1], @vector[padre-1] = @vector[padre-1], @vector[i-1]
              i = i / 2
              padre = i / 2
          end
      end

• hundir: sería la contrapartida a flotar. En este caso, lo que se hace es que, si eliminamos la cima del montículo, la acción rápida, sería mover el último elemento del vector al principio, cambiar el dimensionamiento del vector y realizar este algoritmo para llevar (o hundir) al elemento a su posición correcta. Igualmente, el algoritmo es lineal:

      def hundir(i)
          begin
              hi = 2 * i
              hd = 2 * i + 1
              p = i
              if (hd <= @vector.length and @vector[hd-1] > @vector[i-1])
                  i = hd
              end
              if (hi <= @vector.length and @vector[hi-1] > @vector[i-1])
                  i = hi
              end
              if (p != i)
                  @vector[p-1], @vector[i-1] = @vector[i-1], @vector[p-1]
              end
          end until p == i
      end

• insertar: en este método, insertamos (como bien dijimos en flotar) un elemento en la estructura, por lo que, hacemos eso mismo, agregamos el elemento y lo flotamos:

      def insertar( e )
          @vector.push(e)
          flotar(@vector.length)
      end

• primero: nos da el primer elemento del montículo (la cima), pero sin eliminarlo de la estructura. Por lo que el algoritmo es:

      def primero()
          @vector[0]
      end

• cima: igual que el anterior, pero eliminando el elemento de la cima. Para ello, como se comentó en hundir, se toma el último elemento, se inserta en la cima (que queda vacía) y se hunde hacia su posición correcta. El algoritmo sería:

      def cima()
          e = @vector[0]
          if @vector.length > 1
              @vector[0] = @vector.pop
              hundir(1)
          else
              @vector = []
          end
          e
      end

• Como ayuda o soporte vamos a crear dos métodos más, uno genérico a Ruby (y presente en otros lenguajes como Java, PHP y Python, pero con distinto nombre) que permite tener una representación en formato texto (o cadena, o string) del montículo: to_s; y otro método que nos dará los elementos del montículo en un vector ordenado (eliminándolos del montículo, claro): ordenado; la implementación de ambos:

      def to_s()
          "[ " + @vector.join(", ") + " ]"
      end
   
      def ordenado()
          a = []
          a.push cima while not vacio?
          a
      end

Una vez visto todo el código, podemos hacer una prueba como la siguiente, en la que insertaremos unos datos aleatorios y obtendremos el resultado de su almacenamiento en forma de montículo, y el resultado en un vector ordenado:

a = [ 6, 4, 3, 1, 5, 2, 4 ]
 
m = MonticuloMaximos.new
a.each do |e|
    m.insertar(e)
end
 
puts m
 
puts "[ " + m.ordenado.join(", ") + " ]"

El resultado es el siguiente:

[ 6, 5, 4, 1, 4, 2, 3 ]
[ 6, 5, 4, 4, 3, 2, 1 ]

NOTA: Como se podrá ver en la implementación, este código estaba preparado para vectores que enumerasen sus elementos en base a 1..N, y sin embargo, todos los lenguajes (a excepción de Pascal, Modula-2, y otros similares) numeran los vectores de 0..N-1, por lo que en cada acceso al atributo @vector se ha tenido que decrementar en 1 el número, para pasar de la notación 1..N a 0..N-1.

Conclusiones

El montículo es un gran elemento que se sigue empleando por su simpleza y óptima respuesta, ya que en lugar de emplear estructura de árbol, grafos o listas, emplea un simple vector, por lo que cada acción a realizar sobre él resulta con un coste bastante reducido. Así mismo, como había dicho al principio, esté presente en todos los lenguajes, ya sea con el nombre de heap, o PriorityQueue, con la capacidad de poder implementar su comparador (para máximos, mínimos o a medida), por lo que no hay excusa para no emplearlo cuando la situación lo requiera.

Con este título nos encontramos un libro bastante curioso sobre esta tecnología, y digo tecnología, porque no solo cubre el lenguaje de programación funcional Erlang, sino también el framework de desarrollo OTP. El libro se estructura de forma que la introducción al lenguaje es efímera pero clara, y nos plantean, casi desde el principio, la creación de un proyecto de caché, al que van agregando los elementos de OTP, hasta culminar en un proyecto completo, funcional, y que contiene, desde la práctica, todos y cada uno de los elementos que podemos encontrar en el framework OTP.

Da un recorrido por las herramientas de Erlang, de monitorización, de depuración y los profilers, así como Mnesia (la base de datos que trae consigo Erlang) y los mecanismos para crear, publicar y actualizar en caliente aplicaciones en Erlang.

Sus autores, entusiastas de Erlang, trabajan en el proyecto Erlware, además de mantener el libro. Estos son Martin Logan, Eric Merritt y Richard Carlsson. El prólogo está escrito por Ulf Wiger, CTO de Erlang Solutions.

Comentar, simplemente, que el libro me ha gustado mucho por su carácter directo. Muestra un proyecto en proceso de creación con código completo y explicando, no solo la historia de cada uno de los elementos y el porqué funcionan y se comportan como se comportan, sino también mostrando la utilidad práctica y para el proyecto de cada elemento, siendo como ejemplo de uso de los elementos de que dispone Erlang/OTP.

Su redacción es amena y para nada pesada y, aún siendo una temática muy densa, se desarrolla con ejemplos, código y gráficos a lo largo de unas 370 páginas, aproximadamente, quedando explicado todo de forma muy concisa y clara. El autor se centra sobretodo en OTP y el desarrollo de soluciones reales más que en la sintaxis y propiedades del lenguaje, con lo que consigue que el texto sea más pragmático y menos académico que el propio libro de Joe Armstrong.

Recomiendo su lectura para todo aquél que desee aprender Erlang/OTP con una curva de aprendizaje más suavizada.

Analizar esa simple expresión nos lleva a una regla importantísima que nos permite diseñar programas orientados a objetos y orientados a concurrencia, que sean muy óptimos y fácilmente trazables. Nos lleva a la vía en la que realizar TDD se hace obvio, y la deuda técnica desaparezca, facilitando refactorizaciones, encontrar fallos y desarrollar software con elementos pequeños, y combinando estos elementos (tal y como reza la filosofía unix) de modo que se pueda construir algo mayor, a alto nivel, sin perder el control granular de la programación a bajo y medio nivel.

Programación Orientada a Objetos

Imaginemos que tenemos que crear un programa en el que se administra un almacén. Este almacén tiene objetos que pertenecen a varias categorías, y se tiene que mantener un peticionario de las tiendas que solicitan una reposición de ciertos productos. Si lo pensamos entorno a base de datos, diagramas de Entidad/Relación (E/R), obtenemos las entidades: productos, categorías, tiendas, solicitudes; con sus respectivas relaciones.

Usando programación orientada a objetos, obtendremos que ese diagrama de clases se puede especificar muy fácilmente a través de la creación de las diferentes clases. Podemos usar algún método de persistencia, y tendremos nuestros elementos, con funcionalidad agregada dentro de cada uno de las clases, por ejemplo, en solicitudes: solicitaProducto, asociaTienda, …. ya depende de cómo lo queramos (o podamos) montar.

Ahora, si una clase como productos, de pronto agrega más funcionalidad, como por ejemplo fabricaProducto, compruebaDisponibilidad, … podemos ver que el producto ya tiene varias responsabilidades, es decir, tendremos la propia responsabilidad de mantener los datos del producto, comprobar su caducidad, etc. a responsabilidades como fabricaProducto que debería de estar en una clase de tipo fábrica, o compruebaDisponibilidad, que debería de estar más bien en una clase de tipo almacén.

Si no respetamos esta norma, el contrato entre objetos se convierte en un auténtico caos, que puede derivar en ejecuciones difíciles de trazar y con resultados inesperados.

Programación Orientada a Concurrencia

En este caso, nos encontramos que definimos código que se ejecutará como un proceso aislado, estos códigos pueden ser, al igual que en el ejemplo anterior: productos, categorías, tiendas y solicitudes. La unidad de persistencia igualmente se puede conseguir de cualquier forma que se desee (fichero o base de datos).

En lugar de instanciar objetos, procedemos a crear procesos. Cada proceso al ejecutarse tiene su propio espacio de memoria, y de cada código específico se pueden generar tantos procesos como se necesiten. La llamada a los métodos, tal y como se llama en programación orientada a objetos: paso de mensajes; se consigue así mismo, realizando una petición o enviando un mensaje al proceso. Por lo que, por ejemplo, a un proceso de tipo solicitudes, podemos pedirle solicitarProducto, asociaTienda, … o cualquier otra función que tenga montada el sistema.

Al igual que el caso anterior, la responsabilidad de un proceso debe de ser única. Si no se cumpliese la norma, podríamos encontrarnos con interbloqueos al intentar llamar o solicitar dos cosas al mismo proceso por bucles (o lazos) generados sin darnos cuenta.

Conclusiones

Las metodologías nos ayudan a desarrollar de una forma más organizada nuestros programas. Desarrollar software con ayuda de patrones y normas como esta, hacen que el software sea más claro y fácil de trazar, así como de ampliar y mantener. Además, estos son estándares en la industria del software, con lo que, cualquiera que conozca los patrones y normas específicas, puede entender el código y sumarse al desarrollo y ampliación del mismo sin problemas.

Esto puede constituir un pequeño desastre para todos los servicios que tengo montados, ya que hay que copiar todos los datos al nuevo servidor, tirar el servicio antes para que los datos no cambien, y levantar los servicios en el nuevo, asegurándose de que todo funcione… vale, por ahí, ya sé que van a ser un par de horas… pero el DNS… con su propia caché y demás, eso sí puede ser un gran problema.

Por ese motivo me puse a buscar y, a modo de post-it, me lo dejo aquí escrito para futuro, y por si alguien lo necesita también. Básicamente es: cómo redirigir el tráfico de un servidor a otro, empleando iptables.

Redirigiendo…

Vale, estoy en el antiguo servidor, tengo email y web. Los puertos por los que llega la comunicación, todos TCP, y posibilidad de SSL, pero en eso no hay mayor problema. En esencia tengo que cuidarme de las peticiones a los puertos: 80 (http), 443 (https), 25 (smtp), 465 (ssmtp), 110 (pop3), 995 (pop3s), 143 (imap) y 993 (imaps).

Buscando, vi esta web sobre como redireccionar tráfico, por lo que, escribí:

echo 1 >/proc/sys/net/ipv4/ip_forward
export IP=XXX.XXX.XXX.XXX
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination $IP
iptables -t nat -A POSTROUTING -p tcp -d $IP --dport 80 -j MASQUERADE

NOTA: como es lógico, hay que cambiar XXX.XXX.XXX.XXX por la IP del servidor al que se quieren redireccionar las peticiones al puerto 80.

Lo que hacen estos comandos es:

1. Indica al kernel que puede hacer forward de los paquetes que pasen por su interfaz de red.
2. Indica al sistema que los paquetes entrantes al puerto 80 sean dirigidos a la $IP indicada.
3. Indica al sistema que los paquetes que deban de salir, se emascaren modificando su IP de origen por la propia.

Con esto conseguimos que la comunicación hacia el puerto 80 pase sin problemas al otro servidor. Lo único, es que se desvirtúan las estadísticas, ya que para el servidor web, todas las peticiones son del servidor que redirecciona las peticiones, pero si es un recurso temporal (como es mi caso), no tiene mucha o mayor importancia

¿Cómo funciona el enrutado?

Encontré también otra página donde se explica bastante bien (aunque algo esquemática) la forma en que funciona el enrutado de paquetes empleando iptables, el gráfico:

Como puede verse, el paquete pasa por la cadena de reglas PREROUTING al entrar, es procesado y, cuando se detecta que es para otra máquina, se pasa a FORWARD y después a POSTROUTING, donde se pueden agregar reglas de modificación antes de que el paquete sea entregado a su destino.

Recomiendo echar un vistazo al enlace dado para ampliar más sobre el tema.

Conclusiones

Nada es perfecto al 100%, por ejemplo, esto mismo lo probé con XMPP, y no funciona correctamente, ya que la comunicación de s2s del protocolo espera que los mensajes lleguen del dominio (e IP) al que se solicita información, mientras que, estos mensajes, en su mayoría, al estar direccionados al dominio, no es la misma IP. No obstante, como medida temporal y sobretodo para HTTP, el apaño lo da.

Según Dahl: estuve involucrado, de vez en cuando, escribiendo códigos pequeños orientados a eventos. Me gustó el diseño de los servidores orientados a eventos porque sentía que eran más fáciles de comprender: el estado es mantenido en alguna estructura y puedes girar y girar modificando el estado. No había un bucle infinito haciendo bloqueos de lectura o aceptaciones desde los sockets. Me veía capaz de hacer servidores de muy baja latencia usando solo E/S sin bloqueos.

La estructura

Node.js es un intérprete JavaScript mono-hilo, lo cual indica que, la ejecución de un programa, es individual, no se puede diseccionar y, por lo tanto, no comparte información con otros hilos (ya que no los hay), ni con otros procesos, a menos que sea por paso de mensajes de comunicación entre ellos.

El sistema se basa, por sus librerías creadas a tal efecto, en la programación orientada a eventos. Si se quiere crear un servidor que escuche de un determinado puerto, por ejemplo, un servidor web, podemos emplear el siguiente código:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, "127.0.0.1");
console.log('Server running at http://127.0.0.1:1337/');

Si lo lanzamos con el comando: node http.js; veremos que se ejecuta y al lanzar un navegador a la URL que indica el sistema, en el navegador podemos ver el texto Hello World. Podemos ver igualmente que si agregamos una espera al proceso, tal que así:

var http = require('http');
http.createServer(function (req, res) {
  var now = new Date().getTime();
  while (new Date().getTime() < now + 5000) {
    // nothing
  }
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, "127.0.0.1");
console.log('Server running at http://127.0.0.1:1337/');

El sistema espera 5 segundos antes de dar el mensaje, por lo que si abrimos varias lengüetas, pestañas o ventanas del navegador, nos daremos cuenta de que las peticiones se realizan de forma secuencial, esperando 5 segundos cada petición, cuando la anterior termina.

Librerías específicas

Dahl seleccionó ECMAScript (ya que V8 se basa en este y no en JavaScript… aunque realmente ECMAScript sea una estandarización de JavaScript), porque está poco desarrollado en base a librerías. ECMAScript se ha empleado siempre de forma embebida y sobretodo en navegadores, por lo que las librerías de funciones y objetos siempre han sido portadas por los navegadores y fuera de ese contexto, no tienen gran utilidad.

La librería del sistema http es una de las muchas que podemos encontrar en Node.js, hay otras como File, JSON, LDAP, sql, MD5, … todas ellas con la capacidad de instalarse de forma muy simple:

npm install JSON

El listado y búsqueda de paquetes se puede realizar a través de la página oficial de npm. Las librerías que ya vienen instaladas se pueden ver aquí, junto con su documentación.

Conclusiones

Node.js es en sí un intérprete con librerías y una metodología detrás que da que pensar. Como en artículos anteriores, he hablado muchas veces de que JavaScript se ha considerado muchas veces un lenguaje de futuro. Quizás con Node.js, alcanzando un nivel de formalización adecuado, quizás podamos ver ese futuro más férreo y no tan difuso.

Cabe destacar que, entre las extensiones diponibles, se encuentra coffescript, por lo que, también es posible que encontremos diversidad a medida que vaya creciendo el proyecto. De momento, y después de vista la entrevista de hace un año y los progresos que sigue teniendo, se augura un buen futuro a para esta herramienta.

Las gemas de Ruby son paquetes de librerías para Ruby que se instalan en el sistema y quedan listas para ser usadas, con un simple require o con mecanismos que aporta el propio sistema de gemas para Ruby.

El gestor de gemas: rubygems

En distribuciones de GNU/Linux, e instalaciones automáticas para Windows, se nos habilita un comando, generalmente, que nos permite agregar librerías y código de un repositorio muy extenso de código listo para usar. Esto es conocido como el gestor de gemas, rubygems, o simplemente gem.

El gestor de gemas es un comando que nos permite listar las gemas instaladas, buscar gemas remotas o localmente (de las instaladas), instalar, actualizar y eliminar gemas. Se puede saber si está instalado simplemente ejecutando:

gem --version

La última versión a día de hoy es la 1.8.12, actualizar el sistema de gemas es tan simple como ejecutar:

gem update --system

Instalar una gema

Por ejemplo, si queremos usar el código siguiente:

require "rubygems";
require "json";
 
puts [ "hola a todos", 12, "C/Sin nombre, 25" ].to_json

Tendremos que instalar previamente la gema json. Para instalarla, solo tenemos que ejecutar el siguiente comando:

$ sudo gem install json
[sudo] password for marubio: 
Building native extensions.  This could take a while...
Successfully installed json-1.6.4
1 gem installed
Installing ri documentation for json-1.6.4...
Installing RDoc documentation for json-1.6.4...

Como se puede apreciar, se instala la gema y se genera la documentación para ri y rdoc. La generación de la documentación es bastante lenta y si tenemos que instalar muchas gemas, puede ser algo tedioso. Se puede eliminar esta tarea agregando al comando de instalación: --no-ri --no-rdoc

Ahora, cuando listemos los paquetes instalados podremos ver:

$ sudo gem list
 
*** LOCAL GEMS ***
 
json (1.6.4)

Nos indica la versión, ya que podríamos tener varias versiones instaladas y conviviendo, y desde el código emplear la que requiramos específicamente. Si queremos instalar una versión específica de un paquete, podemos hacerlo agregando la opción, por ejemplo: --v=1.6.1

Buscando una gema

Si queremos buscar una gema específica del directorio de gemas, podemos hacerlo a través de la propia página web: RubyGems; o a través del comando:

$ gem search -r jsonn
 
*** REMOTE GEMS ***
 
active_record_serialize_json (0.1.2)
activejson (0.1.2)
activeresource_json_patch (0.0.1)
assert_json (0.1.1)
capcode-render-json (0.2.0)
capybara-json (0.1.1)
colorful_json (0.9.1)
csv2json (0.2.0)
cucumber-json (0.0.2)
dm-json-search (0.0.3)
[...]

La base de datos de gemas tiene la friolera de más de 32 mil gemas, por lo que, no es de extrañar que ante algo trivial (como JSON) puedan aparecer cientos de gemas. A la hora de buscar deberemos de ser más precisos con los términos a elegir.

Conclusiones

Ha sido una introducción muy ligera a este entorno de gestión de paquetes de Ruby, lo sé, pero al menos complementa un poco la entrada de hace algunos meses sobre Bundler y da un poco de información sobre los comandos más usuales a la hora de instalar una librería en Ruby, ya sea para código scripting o para Rails.

Según vemos en la página oficial del proyecto, NewSQL dispone a día de hoy de dos posibles gramáticas a implementar. Una de ellas está basada en la Java Database (JDB) y otra sería la evolución propia de SQL (SQL II, o S2). Aún no se ha decidido qué versión será la empleada como newSQL, por lo que, podemos decir que es un proyecto a futuro y no hay implementación real de momento.

Implementación JDB

La sintaxis que se desea implementar al estilo JDB tendría esta forma en comparación con el SQL actual:

La sintaxis puede parecer bastante clara y limpia, sobre todo para los que programan con lenguajes del estilo de Java, C++, PHP y de sintaxis derivada. No obstante, si tenemos en cuenta que esto sustituye a SQL, pero no a la forma de enviar las consultas, generar una cadena de texto de este estilo para enviarla al Sistema Gestor de Base de Datos, puede resultar bastante tedioso igualmente.

Hay bastantes dudas sobre, por ejemplo el INSERT, ya que, ahí nos muestran una inserción completa, pero, ¿y si queremos que haya datos por defecto y solo declarar algunos? … igualmente, en la cadena de búsqueda, da la sensación de haber empleado XPath para seleccionar las tuplas… ¿cómo se haría si se busca por un criterio en lugar de un ID? … al final puede quedar algo difícil de entender, realmente.

SQL II (S2)

La otra opción, es una versión evolucionada de SQL (o simplificada, según se mire), que tiene la siguiente forma:

Revisándolo, se ve claro que no aporta mucho, realmente, a lo que se usa de hoy en día. Es más, se intenta introducir de forma fija el uso del operador “==” en lugar de “=”, lo cual resulta extraño e inapropiado, desde mi punto de vista, ya que, en todo caso, cambiaría mejor el “=” del UPDATE por un “<-”.

Conclusiones

Desde mi punto de vista, más que centrarse en cómo escribir “mejor” los sistemas SQL, deberían de centrarse en agregar dichas sentencias para que se mezclasen con el código, algo como SQLJ, de cara a integración con los lenguajes, y de cara al mejor uso de SQL, hacer estándares del uso de las fechas (que cada sistema los usa a su forma), así como los LIMIT, funciones básicas y tipos de datos, entre otras muchas cosas, para que los SGBD fuesen más compatibles entre ellos.

Esta herramienta es para poder realizar pruebas de sistema, a nivel completo y desde la propia interfaz de usuario… o incluso de forma automatizada, desde scripts de tipo JUnit, Rspec, y otros entornos de pruebas unitarias o de sistema automatizados.

La URL para descargar Selenium es: Selenium Downloads; ahí podremos descargar los entornos, entre ellos el mencionado Plugin para Firefox.

El resto del artículo irá dirigido, sobre todo, a revisar Selenium IDE, que es el que se maneja desde el propio plugin de Firefox, y es la parte más visual y rápida para adentrarse en este entorno de pruebas.

Lanzando el IDE

Una vez se tiene instalado el plugin (no lo comento, puesto que es una instalación básica y guiada, por lo que considero no debe de surgir mayor problema), pasaremos a lanzar el IDE. Este se encuentra en el menú Herramientas (o Tools), bajo la opción Selenium IDE, tal y como se ve a continuación:

Tras esto, se abre una ventana, la del IDE de Selenium, y si os fijáis en la parte derecha de la barra de herramientas, el botón de grabación, ya está presionado, con lo que, si hacéis algún clic, escribís algo en algún formulario de cualquier página que esté abierta en el navegador, se almacenará a modo de comando en el IDE de Selenium dicha opción:

En el momento que volvamos a presionar el botón de grabación, o se seleccione la opción Actions –> Record, se detendrá la grabación y con las opciones de ejecución: Play entire test suite, o Play current test case; se puede reproducir lo grabado, ya sea de forma completa o solamente la línea seleccionada, respectivamente.

Automatizando

Está claro que, podríamos tener Chrome, Firefox, Internet Explorer, Opera, … todos los navegadores posibles para comprobar que el funcionamiento de nuestra aplicación es el que debe de ser… pero resultaría bastante tedioso el tener que lanzar cada navegador (e incluso en cada infraestructura: Windows, Linux, MacOS X, Android, …), por lo que Selenium también nos da otras herramientas.

En principio, desde el entorno, cada test suite puede ser exportada como prueba a: C#, Ruby con Test::Unit o Rspec, JUnit o Python; existiendo también otros exportadores aparte para otros lenguajes, como PHP u otras librerías que permiten escribir el código de tipo Selenium en lenguajes como Erlang.

Webdriver

Nada más entrar en la web, además del entorno IDE del que ya he comentado algo, encontramos que hay dos opciones elementos más disponibles: Remote Control y Webdriver; actualmente, Remote Control ha sido desestimado y en su lugar se emplea Webdriver, por lo que nos centraremos en Webdriver.

A través de la documentación oficial, podemos ver que WebDriver es un framework que se puede emplear en nuestros proyectos de Java, C#, Python, Ruby, PHP o Perl (que son los oficialmente soportados, también está disponible en este enlace Erlang, y hay otros desarrollados por la comunidad.

Grid

Grid es la parte servidora, es decir, un hub o rejilla donde se pueden agrupar servidores de este mismo tipo, de modo que las pruebas se les puedan encargar a ellos. La propia web dedicada a ello de Selenium Grid, How it works, nos muestra como funciona la idea:

Básicamente, consta de que, cada WebDriver pueda ser manejado de forma remota a través de un Grid. De este modo podemos tener varias arquitecturas como Windows, Linux, MacOS X, … y varios navegadores como Firefox, IE, Chrome, Safari, … en nuestra rejilla, y encargar las pruebas para que se realicen en general a todas las plataformas, al mismo tiempo.

Conclusiones

Es un buen entorno para pruebas, y realmente no resulta nada tedioso el desarrollar las pruebas directamente en el IDE, modificarlas y ajustarlas, verificarlas y exportarlas finalmente para la rejilla de pruebas.

¿Qué es un CMS exactamente?

Un CMS es un sistema de administración de contenido (Content Management System), básicamente. Zotonic se centra en esto mismo, administrar el contenido de la web que está sirviendo. A diferencia de otros CMS realizados en otros lenguajes, Zotonic tiene la ventaja de ejecutarse en una máquina que permite la ejecución de software fuera de la petición.

Por ejemplo, en otros lenguajes como Ruby, Python, Perl o PHP, cuando una petición HTTP llega al sistema establece el contexto de ejecución (sesión, cookies, datos de la solicitud, etc.) y tras su respuesta, el contexto es liberado (o volcado a la memoria secundaria), con lo que, es imposible mantener una ejecución paralela que dispare el sistema.

Es más, hay herramientas como delayed::job (en Ruby) o DJJob (en PHP), precisamente para paliar un poco esto.

Sin embargo, Zotonic, tiene como ventaja el hecho de que puede disparar la ejecución de un proceso no dependiente de la solicitud que almacene su resultado en una cola de mensajes que sea descargada por el sistema AJAX de la vista para mostrarlos en el momento que sea necesario. Esto le da a Zotonic una sensación de rapidez y paralelismo que pocos entornos web tienen hoy en día.

¿Qué ofrece Zotonic?

En principio, Zotonic se puede instalar en una máquina o en varias (en clúster) manteniendo una única interfaz de administración y pudiendo balancear entre todas el acceso, de forma fácil y transparente. Además, cada clúster puede administrar varios dominios:

Su interfaz es muy parecida a WordPress, y permite igualmente escribir páginas y entradas de modo que se puedan emplear como páginas del propio sitio web. Su editor se ve así:

Como base de datos emplea PostgreSQL, y la forma de programar las plantillas es mediante el estándar de Django Template Library (DTL), lo cual facilita la creación de las vistas enormemente. Se puede revisar la documentación que, aunque el tema de las plantillas las trata poco (realmente es porque su simpleza no requiere de mayor información) es una sección de la web bastante extensa conteniendo temas como: SSL, Modelo de Datos, información sobre Erlang, PostgreSQL, conexión Ajax con Zotonic, mensajes Growl, etc.

Una lista bastante extensa y detallada de las características puede verse aquí (en inglés).

Instalando Zotonic

Se puede descargar en cualquier ruta de nuestro equipo, realmente, con el comando:

git clone git://github.com/zotonic/zotonic.git

Esto nos deja un entorno limpio con el que podemos hacer nuestra primera instalación. Por ejemplo, si ponemos en nuestro fichero /etc/hosts al lado de localhost la palabra miblog, podremos escribir lo siguiente:

make
bin/zotonic -s blog miblog
./start.sh

Ahora, solo tendremos que ir a un navegador, si ponemos la URL http://localhost:8000, veremos la interfaz de los dominios que tenemos en ejecución. Solo dispondremos, en estos momentos de miblog, por lo que, como lo hemos puesto en nuestro fichero de hosts, podemos seguir ese enlace y ver la web de nuestro sitio.

Si accedemos por la URL http://miblog:8000/admin/, nos preguntará por el login de acceso y contraseña. Este será, en principio (deberemos de cambiarlo): admin / admin; tras esto, se nos presentan todas las opciones disponibles de Zotonic… ¡y en castellano!

Todo queda bastante claro y muy fácil de manejar, a excepción de las plantillas, las cuales solo se pueden modificar a través de la edición de los ficheros en el directorio donde se haya creado el dominio. En este caso, como hemos creado el dominio miblog, la ruta será: priv/sites/miblog/templates.

Conclusiones

Zotonic se ha convertido en poco tiempo en un CMS con amplias características y muy usado en el mundo del web, aunque no tanto como otros que llevan más tiempo como por ejemplo Zope, Drupal o Joomla, pero poco a poco, gracias a sus características propias de alta disponibilidad, redundancia y escalabilidad, de seguro comenzará a ser cada vez más popular.