Definiciones

Los grafos son nodos (o vertices) unidos por líneas (o aristas). Según las aristas podemos encontrarnos grafos no dirigidos o grafos dirigidos, según si las aristas tienen dirección o no.

Un ejemplo de grafo no dirigido:

La forma de representar el gráfo en modo de ecuación es G = (N, A), siendo N(G) el conjunto de nodos (vértices) y A(G) el conjunto de aristas del grafo. La representación del grafo de ejemplo sería el siguiente:

N(G) = { 1, 2, 3, 4, 5, 6 }
A(G) = { (1,2), (1,6), (6,4), (4,5), (2,3), (2,4) }

Una arista que se enlaza un nodo consigo mismo se la denomina bucle o lazo.

Dos nodos son adyacentes si siendo distintos existe una arista que los une.

El grado de un vértice (o nodo) es el número de aristas que entran o salen de él.

Un camino es una secuencia de aristas consecutivas. La longitud del camino corresponde al número de aristas que contiene. Hay dos tipos de caminos:

• camino simple, es un camino que no emplea más de una vez la misma arista;
• camino compuesto, cuando el camino emplea dos veces la misma arista (aunque no de forma continua).

Un ciclo (o circuito) es un camino simple que empieza y termina en el mismo vértice.

Un ejemplo de grafo dirigido:

La forma de representar el gráfo en modo de ecuación es G = <N, A>, siendo N<G> el conjunto de nodos (vértices) y A<G> el conjunto de aristas del grafo. La representación del grafo de ejemplo sería el siguiente:

N(G) = { 1, 2, 3, 4, 5, 6 }
A(G) = { <2,1>, <1,6>, <6,4>, <4,5>, <3,2>, <2,4>, <4,4> }

El grado de un vértice (o nodo) en el grafo dirigido, puede ser de:

• grado de entrada (o entrante) de un vértice que es el número de aristas que llegan a él (con dirección hacia él); y el
• grado de salida (o saliente) de un vértice que es el número de aristas que salen de él (con dirección hacia otros vértices).

Un camino, en un grafo dirigido, es una secuencia finita de aristas entre dos vértices, siendo el extremo final de cada arista el extremo inicial de la siguiente.

Un grafo dirigido es fuertemente conexo si para cada par de vértices distinos n y m hay un camino de n a m y viceversa. El grafo dirigido expuesto como ejemplo tiene esta propiedad, ya que se puede acceder a cualquier nodo desde cualquier otro.

Dos vértices o nodos están conectados si hay un camino que los une.

Las aristas, al igual que los vértices, también pueden contener información, este es el caso de los grafos etiquetados (o valorados). Se representan de la siguiente forma:

G = (N,A,P)
N(G) = { 1, 2, 3, 4, 5, 6 }
A(G) = { <2,1>, <1,4>, <4,3>, <3,2>, <2,4>, <4,5>, <6,4> }
P(G) = { 5, 8, 1, 10, 2, 6, 7 }

La representación gráfica:

Tipos de Grafos

Realizando, según sus propiedades, una categorización de grafos podemos distinguir los siguientes tipos:

• grafo no dirigido, es un grafo cuyas aristas no tienen dirección.
• grafo dirigido, es un grafo cuyas aristas tienen dirección;
• grafo nulo, es un grafo sin vérticos (y por ende, sin aristas);
• grafo acíclico, es un grafo que no contiene ciclos (o circuitos), el gráfico presentado como grafo dirigido es acíclico;
• grafo etiquetado (o valorado) es un grafo dirigido con pesos definidos en sus aristas;
• grafo conexo, aquél para el que, tomando cualquier par de vértices que lo forman, existe un camino que los contenga;
• grafo simple, es aquél que entre cada par de vértices existe a lo sumo una arista;
• multigrafo, el caso contrario al grafo simple.
• subgrafo, es el formado por un subconjunto de vértices y aristas contenidos en el grafo del que deriva.
• árbol libre, es un grafo acíclico, conexo y no dirigido. Estos árboles no tienen raíz y los hijos no están ordenados. Para obtener un árbol general hay que seleccionar un nodo como raíz y establecer algún orden entre los hijos de cada nodo.

Subgrafos no dirigidos

Un subgrafo conexo maximal, es un grafo G’ que deriva de G, que está contenido, de ninguna forma, en otro subconjunto posible de G. Por ejemplo:

Este subgrafo (G), puede contener a dos subgrafos:

N(G') = { 1, 2, 3 }
A(G') = { <1,2>, <2,3> }

N(G') = { 4, 5, 6 }
A(G') = { <6,4>, <4,5> }

Como cada uno de estos subgrafos es máximo, es decir, de forma conexa, no se puede incluir ningún otro nodo del grafo padre que pueda completar más el subgrafo, a cada uno de los subgrafos se les llama conexo maximal.

Se denomina componente conexa de un grafo, a un subgrafo conexo maximal.

En cambio, si el grafo fuese así:

Sería posible, para el primer N(G’) agregar el nodo 4, e incluso el 5 o el 6, de modo que, este subgrafo, deja de ser conexo maximal.

El máximo número de aristas en un grafo no dirigido de n vértices es n(n-1)/2. Si tiene ese número de aristas se dice que es completo. No se cuentan los bucles.

Subgrafos dirigidos

El grafo dirigido que no es fuertemente conexo, un subgrafo fuertemente conexo maximal recibe el nombre de componente fuertemente conexa del grafo. El ejemplo tiene dos componentes fuertemente conexas:

Las dos componentes fuertemente conexas serían:

N(G') = { 1, 2, 3 }
A(G') = { <1,2>, <2,1>, <2,3>, <3,2> }

N(G') = { 4, 5, 6 }
A(G') = { <6,4>, <4,6>, <4,5>, <5,4> }

El máximo número de aristas en un grafo dirigido de n vértices es n(n-1). No teniendo en cuenta los bucles.

Representación de los Grafos

Los grafos se pueden representar de varias formas, pero las dos más comunes son: la matriz de adyacencias y la lista de adyacencias.

Matriz de adyacencia

Se crea una matriz (la llamaremos MA por Matriz de Adyacencias) asociada a G, de modo que tenga n x n elementos. Indicaremos sus contenidos con 0 y 1, siendo 1 que en la posición MA[i,j] existe una arista y 0 lo contrario.

Un ejemplo, viendo este grafo dirigido:

Su matriz de adyacencia sería la siguiente (teniendo en cuenta las filas como el origen y las columnas como el destino):

En los grafos no dirigidos cada arista es simétrica. En el caso de los grafos valorados, los valores que se representan en la tabla ya no serían 0 y 1, sino el valor del peso de cada arista.

Determinar cuántas aristas hay en un grafo tiene un coste de O(n²), y requiere de un espacio de memoria de θ(n²). Por lo que no es aconsejado si hay pocas aristas.

Listas de adyacencia

Se representa por un vector de n listas, siendo n el número de nodos, por lo que contiene tantas listas como nodos hay en el grafo. Por lo que el grafo que se muestra a continuación:

Tendrá esta representación en formato de listas de adyacencia:

En el caso de los grafos etiquetados, las listas deberían incluir un campo adicional para almacenar la etiqueta asociada a cada arista.

Determinar si existe una arista entre el nodo i y el nodo j puede llevar un tiempo de O(n), ya que puede haber n vértices en la lista asociada de ese vértice en concreto. El coste en espacio de esta representación está en θ(n+a), siendo n el número de nodos y a el número de aristas.

Conclusiones

Hasta aquí he querido llegar de momento en este tema de los grafos. La parte de algoritmia, costes asociados y demás elementos, lo dejo para el siguiente día de estudio.

Criticando su estilo

Es curioso que gente como Damien Katz (creador de CouchDB), o Toni Arcieri (creador de Reia) hayan sido de los primeros (o al menos los que he encontrado) que hayan arrojado una piedra en contra del lenguaje que eligieron para desarrollar elementos que han sido bastante respetados, apoyados y usados.

En este aspecto, otros como Yariv Sadan, han defendido y reconocido algunos de estos comentarios y, tras leer a unos y a otros, me queda la pregunta de, ¿realmente han entendido para qué sirve Erlang?, ¿qué hace y cuales son sus potencias?, ¿cómo sacarle el máximo provecho así como programar orientados a la concurrencia?

Crítica a la sintaxis

Lo primero que critican de Erlang es su sintaxis. Recuerdo la primera vez que vi el lenguaje C, después de haber programado en Basic, Pascal y Modula-2 que dije… ¡qué raro! y ya ni digamos de cuando unos años más tarde comencé a ver Perl…

La sintaxis C-like, como dicen muchos, es muy extendida, pero no es nada comprensible para una persona que comienza desde cero. Niklaus Wirth desarrollo por esto mismo lenguajes como Pascal, para que sirviesen de aprendizaje al modo pseudocódigo. Un código que nada más leerlo, se entienda.

Erlang, en cambio, sigue una metodología más como Prolog, está orientado al desarrollo de funciones matemáticas, por ello, la función tiene una conclusión (->) para su comienzo y termina con un punto final. Cada elemento dentro de la función o expresión matemática se separa por comas, y todo es funcional, es decir, todo elemento en Erlang hace algo y DEBE retornar algo, incluso las estructuras condicionales, por eso tiene la forma que tiene.

Tipos de datos: registros y cadenas de caracteres

Los registros, son a nivel de preprocesador: tuplas. Esto quiere decir que funciones del tipo record_info no existen realmente, por lo que no se pueden emplear variables para pasarle a esa macro y queda el espectro del uso de los registros algo limitado. No obstante, hay algunos trucos que se pueden emplear y existen para paliar esto, en caso de que se requiera/necesite.

Otro de los problemas, con los tipos de datos, son las cadenas de caracteres, las cuales son listas de enteros. Esto no debe de extrañarnos, ya que en todos los lenguajes son listas (o arrays, o vectores) de bytes. En lenguaje C, por ejemplo:

char c[] = "Esto es una cadena";
char d[] = { 'E', 's', 't', 'o', 32, 'e', 's', 32, ..., 0 };
 
printf("%s\n", strcmp(c, d)==0 ? "true" : "false");

Esto nos dará verdadero, ya que ambas son listas de bytes, al igual que en Erlang podemos ver algo parecido con las listas de enteros:

[100,111,103] == "dog".

Lo cual también retornará verdadero.

Rendimiento: Churras con Merinas

Realmente, al leer el artículo de Toni, cuando llego al punto que dice: Erlang sucks at managing memory; habla de una comparación entre Erlang y Azul Vega, un procesador de 54 cores optimizado para ejecutar la JVM.

Un programa con ese procesador y esa JVM, NO se ejecutaría de forma distribuida, realmente, ya que solo se distribuyen las tareas posibles e internas de la JVM entre los cores, en tanto y en cuanto se puedan distribuir estas tareas. No obstante, no está diseñado para conectarse con otros nodos, por lo que NO es escalable. Además, solo tiene cuatro canales para acceso a memoria, por lo que, 27 máquinas de Pentium IV con HyperThreading podrían hacer ese mismo trabajo con Erlang… y aún así aún podríamos poner más hierro a bajo coste para seguir escalando y mejorando el rendimiento del software desarrollado.

¿Es un lenguaje de propósito general?

Erlang fue creado para entornos en los que hubiese que desarrollar software con alto grado de concurrencia, esto lo hace ideal para entornos servidores de cualquier tipo, y actualmente, para los escritorios modernos, donde los programas se ejecutan de forma concurrente, claro.

¿Elrang puede desarrollar web? Sí, ejemplos como ChicagoBoss, o Erlyweb, o Nitrogen lo atestiguan. ¿Erlang puede desarrollar aplicaciones de escritorio? Sí, ejemplos como Wings3D dan crédito de ello. ¿Erlang sirve para desarrollar aplicaciones de servidor? ¡Claro!, para eso fue creado.

En mi opinión, si PHP tiene esa denominación y es un lenguaje de marcas, Erlang DEBE de tenerla

Asignación única… ¿por qué?

Para trazar mejor los códigos, claro, y porque bien pensado, un lenguaje funcional no requiere del uso de tantas variables, por ejemplo, tal y como decía Damien Katz en su artículo, tienes este código:

f(X) ->
  X1 = foo(X),
  X2 = bar(X1),
  baz(X2).

Este código, bien escrito, sería:

f(X) ->
  baz(bar(foo(X))).

¿Quieres agregar logs para que se vean en el cambio de funciones y no los quieres poner dentro de las propias funciones, sino entre las llamadas… pues puedes hacerlo con otras funciones:

log(Caller, X) -> io:format("~s: ~p~n", [Caller, X]), X.
f(X) ->
  log("BAZ: ", baz(log("BAR: ", bar(log("FOO: ", foo(X)))))).

Realmente no es complejo si se escribe y ordena el código de forma adecuada… en otros lenguajes, como por ejemplo C, se pueden escribir cosas como esta:

char *s = "Parsea la cadena";
int size;
for (int i=0, size; s[i]!='\0' && i<100; i++, size++)
  ;

Otros códigos en Perl dan incluso hasta más miedo… pero es como siempre se dice… depende del programador.

El desarrollo en sí

Lo que creo que no se entiende, es que el desarrollo en Erlang, como tal, no es ni escalable, ni redundante, ni aprovecha todos los núcleos y procesadores de las máquinas, así como el resto de núcleos que estén conectados. El hecho de que se pueda aprovechar la forma en la que Erlang fue diseñado, es desarrollar el software de forma concurrente. Con los patrones adecuados.

Por ejemplo, Erlang puede, en un solo nodo, ejecutar casi 2 millones de procesos concurrentes. Esto quiere decir que, cada tarea que haya que realizar, debería de correr en su propio proceso, y este proceso es el que se lanza en el núcleo, procesador y nodo que corresponda. Como cuando se desarrollaba en PVM o MPICH.

Emplear los patrones de OTP es esencial para sacar el máximo provecho de la arquitectura de Erlang, y el crear manejadores de eventos, máquinas de estos, memorias compartidas a través de servidores, etc. debe de realizarse, necesariamente a través de los mecanismos que aporta Erlang.

Si se emplease Erlang para hacer llamadas a Mnesia, desde cualquier parte del código con las llamadas dirty y generando un nuevo proceso por cada petición aislada, tendríamos un programa que puede tiene potenciales errores de concurrencia, y que no aprovecha los nodos que tenga configurados y conectados el sistema.

Conclusión

Me parece muy poco profesional escribir este tipo de artículos, tanto para Tony como para Damien, en los que ponen una serie de circunstancias poco contrastadas y debidas al bajo conocimiento del lenguaje y, precisamente ellos, que han desarrollado grandes herramientas en este lenguaje.

Java, igualmente, es un gran lenguaje, pero como el mismo Tony comenta, requiere de que la JVM cumpla la especificación RTSJ y, en las comparaciones, por ejemplo, hablan incluso de que habría que adquirir un hardware especial para poder desarrollar algo parecido a lo que Erlang hace en cualquier arquitectura, creo que son muy poco objetivos.

Como cuando hablé sobre la liberación de PHP 5.3, esta nueva versión de PHP se va acercando un poco más al ideal de Programación Orientada a Objetos que ya se tiene en otros lenguajes como Python, Ruby, Java, C#, etc.

En esta nueva entrega, como en otras, hay cambios o mejoras sobre algunos elementos, cosas que se agregan al lenguaje y a la biblioteca de funciones (y objetos) y cosas que definitivamente se eliminan.

Deprecated…

Las cosas que se eliminan en esta versión son cosas tan poco usadas como los parámetros de break y continue, que supongo que tendrían su sentido… pero a mi nunca me hicieron falta, realmente.

Las funciones para almacenar datos en la sesión también han sido eliminadas, ya que con el array $_SESSION, se hacían poco útiles. Por lo que los códigos con funciones: session_register, session_unregister y session_is_registered… dejaran de funcionar en esta versión.

También se eliminan definitivamente cosas como y2k_compliance, register_globals, y otras cosas que en la versión antigua ya se marcaron como que se eliminarían a futuro.

Traits

Una de las grandes agregaciones en esta versión son los traits. Esta es una herramienta muy potente en entornos donde la herencia es simple, posibilitando la reutilización de código… más específicamente de los métodos que se desean portar entre clases de distinta índole.

Por ejemplo:

<?php
 trait ezcReflectionReturnInfo {
   function getReturnType() { /*1*/ }
   function getReturnDescription() { /*2*/ }
 }
 
 class ezcReflectionMethod extends ReflectionMethod {
   use ezcReflectionReturnInfo;
   /* ... */
 }
 
 class ezcReflectionFunction extends ReflectionFunction {
   use ezcReflectionReturnInfo;
   /* ... */
 }
 ?>

Esto hace que las clases ezcReflectionMethod y ezcReflectionFunction se puedan beneficiar de las funciones definidas en el trait ezcReflectionReturnInfo, heredando cada una de su respectiva clase padre.

Más información aquí.

Filtrando cabeceras

Se ha agregado un nuevo callback, para cuando se envíen las cabeceras, justo antes de este instante, se ejecute un código personalizado que permita, junto con las funciones headers_list, header_remove y header, enviar solo las cabeceras que se quieran enviar:

<?php
 
header('Content-Type: text/plain');
header('X-Test: foo');
 
function foo() {
    foreach (headers_list() as $header) {
        if (strpos($header, 'X-Powered') !== false) {
            header_remove('X-Powered-By');
        }
    }
    header_remove('X-Test');
}
 
$result = header_register_callback('foo');
echo "a";

Ejemplo del blog de Carlos Ballesteros, header_register_callback en PHP 5.4.

Por defecto… UTF-8

Así es, hasta ahora, el uso interno de cadenas y textos se hacía en ISO-8859-1 o Latin-1. Al igual que en distribuciones como Debian o Red-Hat este valor se modificó a UTF-8, ahora PHP, en esta versión ha modificado su conjunto de caracteres para que por defecto esté a UTF-8. No obstante, esto puede modificarse desde php.ini.

Rendimiento

Parece que se han modificado muchos de los aspectos internos que tienen que ver con la gestión de memoria, arrays y serializaciones. En principio, según se puede ver en esta presentación, PHP en esta versión ha duplicado su velocidad, mientras que ha dividido por la mitad su consumo de memoria. ¡Eso es optimización!

Conclusiones

Hace bastante tiempo, escribí un artículo acerca de las Nuevas Versiones de los Lenguajes de programación. En este artículo, reseñaba cosas de las que a PHP 5.4 ya no le falta nada… o muy poco, pero apenas perceptible.

Realmente, PHP es un lenguaje al que odias o amas… o ambas cosas, ya que tiene cosas que lo hacen un poco insufrible, y sin embargo, son esas cosas las que le dan flexibilidad y gracias a las que se pueden hacer las cosas que se hacen. Con PHP 5.4, las diferencias que mostraban otros lenguajes con respecto a integración de POO se van acortando. Ahora solo falta que todos se actualicen a estas últimas versiones.

En este sentido, el libro persigue que los programadores tengan en cuenta tres objetivos para la escritura de su código: robustez, eficiencia y fácil mantenimiento.

En general, da un repaso a todos los aspectos de Perl, el uso de las variables y nomenclaturas, definición de procedimientos (o subrutinas) uso de paquetes específicos como strict, documentar apropiadamente el código, etc.

Un libro muy recomendable para todos aquellos que quieran progresar en su conocimiento de este lenguaje haciendo buen código.

Para ello, desde hace mucho tiempo, se integran soluciones de lenguajes embebidos (como Lua, que ya vimos hace tiempo), que permiten ejecutarse en un entorno o contexto controlado, donde cualquier fallo no afecta directamente al núcleo del programa principal, solo al propio módulo en sí.

Leyendo un artículo bastante extenso de Zend Developer Zone, encontramos el cómo instalar la solución spidermonkey dentro de PHP para poder realizar código en JavaScript que pueda servir para extender el núcleo de la aplicación que hayamos realizado en PHP.

Instalación

La instalación es algo manual, ya que, al menos en Debian Lenny, no están disponibles las librerías necesarias para hacer que funcione. Los requisitos para poder echar a correr son:

• PHP 5.3 o superior
• Spider Monkey Libraries 1.7 o superior

La instalación de las librerías de Spider Monkey terminan siendo bastante manuales, por lo que las describiré a continuación paso a paso, tal y como viene en el artículo original:

tar -xzvf js-1.70.tar-gz
cd js/src
make -f Makefile.ref
 
mkdir -p /usr/local/include/js/ 
cp *.{h,tbl} /usr/local/include/js/ 
cd Linux_All_DBG.OBJ
cp *.h /usr/local/include/js/ 
cp js /usr/local/bin/ 
cp libjs.so /usr/local/lib/
ldconfig

IMPORTANTE: se debe de tener en ld.so.conf agregada la ruta de las librerías locales /usr/local/lib antes de hacer el último comando o no tendrá efecto (aunque no dé error).

Por último, instalamos desde PECL la librería:

pecl install spidermonkey-0.1.4

Con esto ya tendremos compilado e instalado el código, ya solo nos quedaría configurar la extensión spidermonkey.so dentro del php.ini para PHP pueda encontrar las funciones y objetos que le acabamos de instalar.

Probando, Probando… uno, dos, tres…

Pues nada, una vez tenemos la extensión configurada y funcionando, ya solo nos queda escribir un código para probar que todo funcione como tiene que funcionar. El código más simple que podemos probar es:

<?php
 
// crea un contexto JavaScript
$js = new JSContext();
 
// define variables PHP
$a = 10;
$b = 2;
 
// asigna las variables al contexto JavaScript
$js->assign('a', $a);
$js->assign('b', $b);
 
// define el código a ejecutar
$script = <<<END
  c = a + b;
END;
 
// evalua el script y muestra el resultado
echo "La suma de $a y $b es: " . $js->evaluateScript($script);

Lo cual nos resulta:

La suma de 10 y 2 es: 12

Complicándolo un poco más

Como todo en la vida, se puede hacer más aún. En principio, tenemos una forma de hacerle llegar al contexto de JavaScript las variables definidas en PHP, pero además, podemos:

Uso de funciones

Pasar una función de PHP para poder ejecutarla desde JavaScript:

<?php
// define la función en PHP
function getCircleArea($radius) {
  return pi() * $radius * $radius;
}
 
// crea el contexto JavaScript
$js = new JSContext();
 
// registra la función en el contexto JavaScript (como gca)
$js->registerFunction('getCircleArea', 'gca');
 
// define el código
$script = <<<END
  ret = 'El área del círculo con radio 5 es: ' + gca(5);
END;
 
// evalua el código y muestra el resultado
echo $js->evaluateScript($script);

Esto muestra:

El área del círculo con radio 5 es: 78.53981633974483

Uso de Clases

Supongamos que tenemos definida la clase Cow en PHP y queremos poder emplearla desde JavaScript. Lo que supone crear un nuevo objeto y poder emplearlo. La clase Cow la definimos como a continuación:

<?php
// definición de la clase
class Cow {
 
  private $_name;
  private $_milked;
 
  public function __construct() {
    $this->_milked = 0;
  }
 
  // name setter/getter
  public function setName($name) {
    $this->_name = $name;
  }
 
  public function getName() {
    return $this->_name;
  }
 
  // milking status setter/getter
  public function milk() {
    $this->_milked = 1;
  }
 
  public function getMilked() {
    return $this->_milked;
  }
 
  public function output() {
    if ($this->getMilked() == 1) {
      return $this->getName() . ' ha sido ordeñada hoy.';
    } else {
      return 'Hora de ordeñar a ' . $this->getName();
    }
 
  }
}

Con la definición de la clase, podríamos ejecutar el siguiente código:

<?php
// cargamos el fichero de la clase
include_once 'Cow.class.php';
 
// crea el contexto JavaScript
$js = new JSContext();
 
// registra la clase PHP en JavaScript
$js->registerClass('Cow');
 
// define el código
$script = <<<END
  var c = new Cow;
  c.setName('Molly');
  var d = new Date();
  var ch = d.getHours();
  if (ch > 8) {
    c.milk();
  }
  c.output();
END;
 
// evalua el código y muestra el resultado
echo $js->evaluateScript($script);

En este caso, el resultado sería, dependiendo de la hora del servidor:

Molly ha sido ordeñada hoy.

O bien:

Hora de ordeñar a Molly

Conclusiones

Considero que, cuando se realizan aplicaciones de servidor que requieran de un nivel de personalización alto, es muy útil poder darle la posibilidad al usuario, o programador en caso de que sea un framework, de extender la funcionalidad propia del entorno, sin afectar con ello al núcleo de la aplicación o servidor.

Spidermonkey, en este aspecto, tiene la ventaja de que cumple con creces las necesidades que puedan surgir en este aspecto, además de ser bastante simple de manejar y, en sí, el lenguaje JavaScript no resulta desconocido para los programadores de PHP, ya que la mayoría son en sí programadores web que, por una causa u otra, han necesitado en algún momento del uso del mismo.

Por mi parte he sido siempre muy comunista con respecto al código, no tengo el menor reparo en mirar, ampliar y corregir código de otras personas y dejo que los demás vean, opinen y corrijan y/o agreguen cosas a mis códigos… es la mentalidad del software libre.

Pero en las empresas ocurre lo contrario. Es muy normal, yo diría que incluso enfermizo, llegar a ver cómo cuando entras en una empresa en la que hay más de tres programadores, cómo cuando algo falla, cuando hay que hacer una nueva mejora, ampliación, adaptación, siempre dice uno en voz alta: ese código es de fulanito; indicando que ni lo va a ver, ni lo piensa modificar.

Concepto de Propiedad del Código

Eso es a lo que se refieren muchos de los autores de las metodologías ágiles. El hecho de que un código sea de alguien, es nocivo, perjudicial, para el desarrollo conjunto de aplicaciones.

Si se quiere desarrollar una aplicación, normalmente, llega hasta el programador (o programadores) que comienzan a escribir el código que hará que esa aplicación funcione. Si nos ponemos en el caso de una aplicación comercial de gestión de clientes, que se separa en modo MVC, y tenemos tres programadores que, se han segmentado y trabaja cada uno de forma autónoma en cada una de las capas, tendremos que entre ellos se comunicarán para hacer peticiones del tipo: Necesito que el modelo valide este dato; No puedo seguir hasta que la interfaz no la termine mi compañero; …

Inconvenientes y Perjuicios

Como he mencionado antes, crear parcelas en una aplicación en desarrollo, cuando es muy normal que se tengan que hacer modificaciones que influyan en todas las partes, hace que cada cambio esté guiado por conversaciones aisladas con gente del equipo que opina que eso no es suyo, que hables con otra persona que es la que lo ha hecho, etc.

Esta actitud crea incertidumbre de vistas hacia arriba, ya que un arquitecto, analista, jefe de proyecto, o director técnico, puede pensar que su desarrollo está demasiado atado a una persona, que puede irse de vacaciones durante dos semanas quedándose todo el trabajo parado, o incluso irse de la empresa, teniendo que hacer herencia de ese código a otros que tendrán que comenzar a estudiarlo.

Desde el punto de vista del programador, realmente y visto en frío, con esta actitud está solo. Es decir, ante cualquier trabajo que haya que realizar nuevo sobre su área, cada error que se produzca, cada tarea o incidencia que caiga en el trozo de código que tiene en propiedad es responsabilidad suya y solo suya, no pudiendo aprovechar la visión conjunta que puede aportar un equipo multidisciplinar.

Propiedad Comunitaria del Código

El hecho de que un código sea de un grupo (no de un individuo) hace que el código sea creado, modificado y ampliado por un equipo, por más de una cabeza pensante, por lo que dará más riqueza al código y se evitarán muchos errores, al ser más ojos los que ven ese código.

En principio, de cara a la alta esfera de la compañía, se ve al equipo de programación como un todo, cada uno puede realizar el trabajo sobre el código que se le diga que debe trabajar (por asignación), ya que es parte del equipo o grupo que lo ha creado.

Puede rotarse la delegación de su tarea (por vacaciones, marcha de la compañía, o baja laboral) en cualquier momento, puesto que sus compañeros saben lo que hacen y sobre qué lo está haciendo.

Ante un error o una incidencia, hay un grupo, un equipo, que puede revisar el código y corregirlo.

Conclusiones

Es sentido común el pensar que esto debería de ser así en todas las compañías, pero aún queda bastante en tema de educación el hacer ver a muchas personas que las cosas que hacen no son suyas, sino que son de la compañía para la que trabajan y en esa misma compañía, junto a ellas, han contratado a compañeros para hacer el trabajo más llevadero, más rápido y más profesional. Si esto no se aprovecha, entonces, no se ganará del intercambio de conocimiento entre personas que sepan más de un campo concreto, ni de la riqueza a la que puede llegar un software cuando se programa por un equipo, no por un individuo.

La práctica se basaba en realizar un sistema para resolver tableros de shikaku, mediante el algoritmo de vuelta atrás. Mi solución es óptima pero no del todo correcta desde un punto de vista académico, ya que el uso del algoritmo (de backtracking) es menos usado de lo que debería.

Para poder ver el código, este puede descargarse a través de un cliente de Subversion, en sistemas Unix/Linux es tan fácil como:

svn co http://project.bosqueviejo.net/svn/shikaku/trunk

Explicación del código

Bueno, tengo que reconocer que, después de algo más de un año de haberlo hecho, he tenido que releer y revisar de nuevo todo para acordarme (y reaprender) cómo hace lo que hace.

Por ello, voy a escribir una documentación básica sobre el código en sí, para tenerla como referencia, cuando tenga que volver al mismo otra vez, y para que sirva a todos aquellos que lo necesiten.

En principio, el código se divide en las siguientes clases:

• shikaku.tablero.Combinacion: esta clase se encarga de almacenar combinaciones. Una combinación es un rectángulo que se sitúa ocupando un espacio de X*Y=N. La combinación debe de tener en alguna de sus casillas el número contenido, por lo que se almacena también la ordenada de N para comprobaciones.
• shikaku.tablero.Ordenada: es cada uno de los números que aparecen en el tablero. Se almacena su posición dentro del tablero y la representación numérica del mismo.
• shikaku.tablero.Tablero: almacena las dimensiones del tablero, la lista de combinaciones fijas (las que solo tienen una combinación válida detectada) y la lista de soluciones posibles para el tablero.

Una ejecución de shikaku tiene los siguientes pasos:

1. Entra en main de la clase shikaku, donde se detecta el origen de datos, hasta saber de donde se va a cargar el tablero.
2. En run se crea una instancia del tablero, y se ejecuta, para cada punto del tablero, el generador de la clase Combinacion.
3. El generador se encarga de buscar combinaciones válidas para el punto dado, dentro del tablero y validando su posición dentro del tablero (es decir, que no haya parte del rectángulo fuera) y con respecto al resto de puntos (que no tenga contenido nada más que el punto del que tiene que hacer la combinación).
4. El último paso para la resolución, es llamando a buscaSoluciones, de la clase Tablero, que se encarga de realizar el algoritmo de vuelta atrás para buscar las soluciones al tablero.

Estos son los pasos más importantes dentro del código para resolver el tablero de shikaku.

La depuración

Uno de los motivos por los que el algoritmo no es del todo de tipo vuelta atrás, es precisamente por el uso de tres algoritmos voraces que se ejecutan antes que el último, de vuelta atrás. Estos algoritmos realizan una criba sobre las combinaciones basándose en tres premisas que debe cumplir cada combinación para ser válida:

1. Que no haya nada fuera del tablero: esto se realiza mediante una simple validación a la hora de generar las combinaciones. Es simple y rápida, y quita mucho procesamiento al algoritmo final.
2. Combinaciones con un solo número: esto se refiere a que dentro del rectángulo que conforma la combinación, solo esté contenido el número objeto de la combinación y ningún otro. Esta validación también está incluida a la hora de generar las combinaciones, para lo que se necesita, en el generador, pasar todos los puntos del tablero.
3. Eliminar combinaciones imposibles: imposibles, además de las que se descartan en los puntos anteriores, son las que colisionan con todas y cada una de las combinaciones posibles de otro número vecino. Si la combinación de un número colisiona con todas las combinaciones posibles de otro número, como es lógico, no podrá ser posible.

Ciertamente, con estos algoritmos se llega a resolver un alto porcentaje de los tableros básicos, sin necesidad de realizar el algoritmo de vuelta atrás. Solo los tableros grandes y con dificultad alta, necesitan, además de estos algoritmos voraces, el de vuelta atrás.

Mejoras

En sentido académico, teniendo en cuenta uno de los requisitos que se pide, que es que sea un algoritmo de vuelta atrás, quizás sea más correcto que la depuradora actúe solo a nivel de rama y no en profundidad.

Hay que tener en cuenta que esto penalizaría el rendimiento y empeoraría en lo que a gestión de memoria se refiere, pero prima más cumplir con los requisitos

El lenguaje Perl me llamó la atención, sobre el resto, porque había sido un lenguaje creado por Larry Wall, un administrador de sistemas… ¡en un mes!, supongo que lo que creó fue la parte más básica del sistema, pero al mismo tiempo la más importante, ya que, como él mismo comenta, Perl fue la simplificación del uso de herramientas como awk, sed, shell script y C.

En la mayoría de trabajos que he tenido, después de eso, cuando un administrador de sistemas desarrollaba algún proyecto, alguna aplicación o decía que programaba, lo hacía en Perl. No en vano, ha sido considerado por muchas distribuciones, empresas y comunidades, como el lenguaje de facto para las actividades típicas de administración de sistemas, entre las que se encuentran tareas tan vitales como: la instalación del sistema, asistentes de configuración, pasarelas intermedias (como amavis)…

Uno de los grandes miedos de la gente que programa en este lenguaje, es la mítica frase de que Perl es un lenguaje write-only, es decir, de los que se usan solo para escribir código que no hace falta mantener (o de usar y tirar), aunque proyectos grandes y la comunidad en sí manteniendo y ampliando el lenguaje, han demostrado que Perl es un gran lenguaje de programación en el que se pueden desarrollar grandes cosas y darles mantenimiento sin problema ni riesgo.

El libro que aconsejo para adentrarse en el mundo de Perl es el que escribió su creador, Larry Wall, aunque a partir de su tercera edición, que está acompañada de mucho más contenido aportado por autores como Tom Christiansen, uno de los primeros que se sumó al mundo y comunidad de Perl; y Jon Orwant, el editor de The Perl Journal, cuya publicación cesó hace ya algunos años.

El libro es algo extenso y asusta al primer vistazo, no en vano son 1070 páginas. Pero una vez se ha abierto y visto el índice, se entiende su extensión y deja de asustar. Realmente, el libro se parte en cinco apartados bien diferenciados:

• Introducción… bueno, esta la podemos leer a modo informativo, o podemos obviarla. Son unas 50 páginas.
• Los detalles desagradables… un título un poco extraño, pero se entiende, porque son los detalles del lenguaje en sí, lo que permite, lo que se puede hacer con él, la sintaxis, los elementos… todo. Es la parte más importante del libro, en mi parecer. Unas 350 páginas, más o menos.
• Perl como Tecnología, nos adentra en lo que hace el intérprete internamente, cómo se puede optimizar su uso, el depurador, los hilos, interfaz con C… sería la parte avanzada del lenguaje. Unas 150 páginas.
• La Cultura de Perl, es el uso de CPAN, el administrador de paquetes, prácticas comunes, seguridad, haciendo Perl portable entre plataformas, documentación, etc. Un poco de Perl en la comunidad y cómo compartir código en la forma en la que lo hacen muchos. Unas 100 páginas.
• Material de Referencia… como no podía faltar, toda la referencia de los paquetes básicos de las librerías que trae consigo Perl. Esta quizás es la parte más extensa del libro, pero la que más se puede emplear en el día a día, realmente.

Una lectura muy recomendable para todos aquellos que quieren adentrarse en la programación de Perl de una forma más íntima, conociendo la comunidad, cómo compartir código, cómo aprovechar el código que ya está disponible para Perl y las mejores prácticas de programación en este lenguaje.

El mundo .NET

Como todo lo que tiene que ver con Microsoft, el mundo .NET se mueve, casi exclusivamente, con productos y herramientas desarrolladas por esta misma compañía. Funciona sobre Windows, con base de datos de Microsoft y se diseña con herramientas de Microsoft.

Lo bueno de Microsoft es que desarrollan los productos para un público general y sin conocimientos extensos. Los lenguajes suelen ser o muy fáciles (Visual Basic) o muy complejos (C++, C#), pero cumplen con todas las necesidades de los programadores a los que van dirigidas las herramientas. Así mismo, tienen un alto nivel de operatibilidad entre los diferentes productos, es decir, escribir código ASP con SQL Server es simple, gracias a ese nivel de compactación y simplificación.

Lo bueno de la simplificación lleva a lo malo de la complejidad también. Un programa que se hace de forma simple y fácil, siguiendo los pasos que Microsoft ha pensado para dar es simple, sencillo y rápido. Pero cuando la aplicación debe tener una forma específica o salirse un poco del camino típico, comienzan a surgir problemas solo saldables con código complejo.

Ximian, absorbida por Novell, ha realizado muchas aproximaciones a este mundo para portarlo al mundo del software libre a través de su escritorio Gnome y su proyecto Mono. No obstante, es un tema un poco espinoso, ya que quien usa software libre, por lo general, se aleja de las tecnologías propuestas por esta gran multinacional, por lo que, aunque es usada y tiene su cuota de mercado, Mono no llega a ser usado tanto como podría esperarse.

El mundo Java

El mundo de Java ha estado siempre en una lucha constante y abriéndose camino en el desarrollo de software, sin mucho éxito al principio, sobre todo en lo que respecta a las aplicaciones de escritorio. Esto fue debido a su naturaleza de pseudo-compilación y pseudo-interpretación, ya que es un lenguaje compilado e interpretado que se ejecuta sobre una máquina virtual, y las labores de interpretación de los bytecodes son algo costosos, en relación a código que se ejecuta de forma nativa.

No obstante, en la parte web, de interfaces, desde que comenzó, ha tenido una gran aceptación, puesto que permite el desarrollo de las aplicaciones en cualquier infraestructura (windows, linux, solaris, …) y se han desarrollado grandes herramientas para el desarrollo en este sentido.

Java siempre es el favorito y preferido de las consultoras (a menos en España), donde es empleado para el desarrollo de aplicaciones, tanto de escritorio como web en todos los sectores donde son contratados.

La mayoría de empresas que han tenido relación con Microsoft y han salido de malas con la grande, han terminado montándose al carro de Java y aportando a esta comunidad en modo de open source herramientas, conocimiento, etc. Además de Sun Microsystems (su fundadora), hay otras como IBM, RedHat, Oracle, etc. que se han sumado al carro de Java para el desarrollo y ampliación de esta comunidad.

Hay comunidades de software libre que se han sumado a la aportación de código para el mundo Java. Esto supongo que será erróneamente aportado como el voto útil, sin saber que en nada se beneficia al software libre en sí, sino solo al mundo Java que, aunque pueda parecer atractiva la idea de luchar contra el tirano, no es más que ayudar a una empresa a derrocar a otra. Esto puede ser muy discutible, sobre todo por los defensores de Java

El mundo del software libre

Al margen de la guerra entre .Net y Java, surgen los entornos, sistemas y elementos de software libre. Pensar que todo el mundo tiene que ser Java o .Net es un craso error, ya que hay muchos elementos que se pueden combinar a gusto propio del desarrollador y emplearlos como mejor convenga para obtener los mejores resultados para una tarea concreta.

A este respecto, una de las comunidades con más auge es la de desarrolladores de PHP, por ejemplo, que es el lenguaje que más proyectos de software libre tiene desarrollados, y es el más usado para el desarrollo de sitios como Facebook, Menéame, WordPress, etc.

Otra de las comunidades más activa en los entornos web es la de Ruby, Ruby on Rails más específicamente, que tiene un entorno fácil y profesional para el desarrollo rápido de sitios web. También Python, con su framework Django. Ambos presentes en el mundo Java a través de JRuby y Jython, respectivamente.

Entornos también desarrollados en lenguajes más específicos como Perl, Erlang, Tcl, etc. hacen que se complete el abanico de posibilidades para el desarrollo de software a través de las soluciones que aporta el software libre.

La nota negativa, es que los elementos no son altamente cooperativos, es decir, aunque se basan en estándares, normas y todos son abiertos, hay que realizar desarrollos para poder tener funcionando cosas entre unos y otros, debido a que en el software libre, no todo está hecho o viene dado fácilmente. Pero la nota positiva sobre esto, es que la dificultad que eso entraña es mucho menor que la que entrañaría el desarrollar algo no hecho o no pensado para hacerse, en Java o .Net.

Conclusión

En principio, no te quedes solo con uno, esto no son tres equipos a los que haya que apoyar a muerte, estas son tres formas de ver la tecnología y puede convenir cualquiera de las tres según el contexto en el que haya que ponerse.

Por ejemplo, en una empresa que se haya invertido en infraestructura y software Microsoft, se tenga todo montado en SQL Server, con ASP e interfaces desarrolladas en Visual Basic, desarrollar cualquier nueva ampliación o una nueva herramienta, cabe pensar que será siempre más fácil si nos ceñimos a lo ya establecido que si comenzamos a cambiar lo que hay.

Igualmente, en otra empresa en la que se haya realizado una inversión para Java, incluso con servidores Solaris, y bases de datos Oracle, no conviene pensar en desarrollar nada con Visual Basic, ni PHP, sino pensar en agregar más aplicaciones de tipo J2EE, que será lo más fácil de implementar.

Por último, en una empresa pequeña, con aspiraciones a crecer, que tengan todo desarrollado en PHP y MySQL, se podría cambiar a un framework de desarrollo para PHP, así como agregar elementos más complejos en caso de ser necesarios (como memcached).

En definitiva, no intentar cambiar lo que ya hay si funciona. Otro caso es que no funcione o que haya que realizar adaptaciones y se pueda aprovechar para agregar elementos más generales o estándares.

El problema viene al querer aplicar escalabilidad al proyecto. Cuando no solo hay un equipo implicado, sino que existen dos o tres, los cuales hay que configurar bajo ciertas circunstancias.

Lo primero que pensé, es que, si le puedo notificar a la red de que sucede un evento en concreto, ya sea a una sola máquina o conjunto definido de estas (pero para todos los equipos la misma configuración), facilitaría la puesta en producción. Con lo que me puse a buscar y encontré MQ, message queue.

El encolado de mensajes

La comunicación de los equipos informáticos se basa en mensajes, en eventos, que deben de poder transmitirse de unos a otros cuando sucedan (si es que se quiere tener la máxima fiabilidad en la información que se trata).

Una forma es comunicar directamente al implicado, lo cual resulta un poco tedioso si los implicados son muchos y muy distintos.

Otra forma es mediante un sistema JMS o un MQ, como RabbitMQ.

El encolado de mensajes es un sistema que permite que un elemento perteneciente a un sistema de información, pueda comunicar un estado, evento o mensaje informativo o imperativo a otro conjunto de elementos dentro del sistema, para que interactúe con él.

Por ejemplo, si tenemos un servidor web, una interfaz, que controla un conjunto de máquinas encargadas realizar llamadas salientes, rastrear páginas de la web para almacenar información para un buscador o similar, y la interfaz quiere enviar parámetros nuevos de configuración a estas, puede hacerlo mediante el envío de un mensaje generalizado a ese conjunto de máquinas, y estas máquinas recibirán el mensaje en el momento que lo soliciten.

Esta utilidad es igualmente buena para cuando una interfaz web, por ejemplo de un estudio fotográfico, carga imágenes desde la web, las retoca con algún tipo de efecto, ajuste, etc. y más adelante permite su descarga. El sistema web puede enviar el evento al sistema de retocado de que hay una imagen disponible, y cuando la imagen ya está disponible, el sistema de retocado puede enviar otro mensaje de vuelta diciendo que ya está.

Quizás esto último podría hacerse mejor con una base de datos, pero con el sistema de mensajería, se eliminan los datos en el momento que ya no se necesitan, mientras que con la base de datos, esos datos podrían permanecer ahí de forma indeterminada.

Conclusiones

Los sistemas de encolado de mensajes tienen su utilidad, sobre todo, en sistemas formados por varias máquinas, con roles bien definidos y en las que se quiere afinar lo que son las conexiones y comunicaciones entre las máquinas.