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.

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.

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.

La pista ya la puso sobre la mesa Delayed::Job, una gema de Ruby on Rails, que crea una tabla en la base de datos, y se encarga de ir actualizando dicha tabla de modo que, en el momento que se lanza el proceso (a través de un cron, por ejemplo), ejecuta todas las tareas que estén esperando en la cola. Realmente es una tabla en la que se inserta cada tarea, y después una ejecución aparte que se encarga de lanzarla.

En PHP, con DJJob, se consigue el mismo resultado. Se crea la tabla para la gestión de los trabajos, y el sistema tiene mecanismos que permiten encolar trabajos y sacarlos para su ejecución, así como preguntar si está en ejecución o terminado. Si adaptamos un poco la tabla, podríamos incluso agregar un campo que nos diese el porcentaje de compleción de la tarea.

Probamos la teoría

Vamos a hacer un simple ejemplo, descargamos el fichero DJJob.php y creamos otros dos ficheros, el example.php:

 
<?php
 
include(__DIR__ . "/DJJob.php");
 
DJJob::configure("mysql:host=localhost;dbname=jobs", array ( 'mysql_user' => 'root', 'mysql_pass' => 'root'));
 
class HelloWorldJob {
        public function perform() {
                echo "Hello world!\n";
        }
}
 
DJJob::enqueue(new HelloWorldJob());

Y el worker.php, que será el que se encargue de sacar el trabajo y ejecutarlo:

 
<?php
 
include(__DIR__ . "/DJJob.php");
 
DJJob::configure("mysql:host=localhost;dbname=jobs", array ( 'mysql_user' => 'root', 'mysql_pass' => 'root'));
 
class HelloWorldJob {
        public function perform() {
                echo "Hello world!\n";
        }
}
 
$worker = new DJWorker(array ( "count" => 1, "sleep" => 0 ));
$worker->start();

Antes de ejecutarlo, necesitaremos tener en la máquina local una base de datos MySQL con este script cargado: jobs.sql; y con acceso root y clave root (se puede cambiar, modificando el código de ambos códigos PHP).

Una vez lo tengamos, solo nos quedará ejecutarlo:

$ php example.php
$ php worker.php
* [JOB] Starting worker host::bosqueviejo pid::18835 on queue::default
* [JOB] attempting to acquire lock for job::1 on host::bosqueviejo pid::18835
Hello world!
* [JOB] completed job::1
* [JOB] worker shutting down after running 1 jobs, over 1 polling iterations

Las opciones del worker, hacen que la ejecución sea solo una, por lo que se puede agregar la ejecución a un cron. No obstante, si no se pasan opciones, la ejecución se hace recurrentemente cada 5 segundos, lo cual es más óptimo si se emplea desde la web. Además, el sistema lanza varios hijos (en caso de tener pcntl_fork) con lo que, trabajará de forma paralela en caso de que haya varias tareas en la cola.

Una buena idea a tener en cuenta si queremos desarrollar cargas de ficheros que tengan un procesamiento bastante extenso, o trabajos de conexión y comunicación con otros servidores (como por ejemplo pagos) que requieran de mucho tiempo y puedan terminar en una desconexión por tiempo de espera agotado, o paciencia del usuario agotada.

Los datos y su acceso

En un principio, me resultó curioso, el sistema de ChicagoBoss había resuelto de una forma muy elegante un problema que llevaba tiempo intentando resolver en Erlang… la definición rápida de los modelos. Para un proyecto de ChicagoBoss, un modelo puede definirse tal que así:

-module(person, [Id, Firstname, Lastname]).

Algo bastante impresionante. Agregado con la posibilidad de conectar con base de datos tan variadas como: MySQL, PostgreSQL, MongoDB, Tokyo Tyrant o Mnesia.

Un “vista”zo

Otro factor bastante curioso, la forma en la que escribir código mezclado con el código HTML en modo de tags, tal y como hacen lenguajes como Ruby (con el erb de rails), JSP, PHP, ASP… me parecía muy curioso y potente al mismo tiempo. La solución acogida por ChicagoBoss ha sido la misma que se empleó en Django (en Python):

{% for person in people %}
 - {{ person.full_name }}
{% endfor %}

El código que hace esta magia es el ErlyDTL.

Por último… los controladores

Los controladores son tan simples de generar como lo son los de Rails. Para quien no haya manejado ninguno de estos sistemas, puede que un ejemplo le resulte aclarador:

-module(book_controller, [Req]).
-compile(export_all).
 
edit('GET', []) ->
   ok;
edit('POST', []) ->
   {redirect, "/somewhere"}.

Como se puede ver, si el controlador atiende a la ruta /book/edit, si lo hace mediante método GET, se ejecutará el primer método retornando simplemente ok. Si se tratase de un formulario con método POST, entraría por el segundo método y se redireccionaría la página a la ruta /somewhere.

La capacidad de gestión de los datos entre los modelos y el paso de estos a través del controlador hacia la vista, es igual de potente que en rails, django y frameworks similares. El controlador se hace bastante simple y puede contener código más volcado al flujo de las llamadas y la lógica propia del sitio web que se desee desarrollar.

Las rutas y la administración… bonus track!

Como agregados, aunque otros frameworks similares tienen también algunas de estas facilidades, como son los ficheros de rutas, nos encontramos por otro lado con la interfaz de administración. La cual nos brinda información del entorno, la posibilidad de escribir ficheros de idioma (para traducir la web) y visualizar las rutas.

Conclusiones

Hace tiempo comentaba la potencia que se comenzaba a ver en el desarrollo de proyectos erlang para la web, ahora, cada vez es más una realidad, gracias a trabajos de tanta calidad como Nitrogen, Erlyweb o este, ChicagoBoss.

Aún no llevo el suficiente tiempo jugando con la herramienta en sí, pero me ha resultado bastante cómoda la generación del entorno (aunque algo buggy… se nota que hay que pulir aún por ahí un poco) y la documentación aún es algo escasa… no obstante, se perfila como un entorno a tener en cuenta por su versatilidad y porque ofrece cosas que en otros entornos son bastante más complejas de conseguir: escalabilidad y redundancia.

Si pensamos en las librerías, en cualquier lenguaje, ya sean módulos, paquetes u objetos, siempre alcanzamos una funcionalidad encapsulada dentro de una forma específica a la que se la puede llamar para realizar una acción. Pero esto cambia radicalmente en los frameworks, u entornos de desarrollo, ya que estos entornos, normalmente, realizan un cierto trabajo, y te permiten extender esa funcionalidad base, con ciertas reglas, a través de código que se escribe.

Se podría pensar en los frameworks como piezas de software que permiten agregar una funcionalidad extra desarrollada por el programador que usa el framework, a modo de addon, plugin o extensión. Pero no es eso. Las extensiones (o llámese como se quiera) son trozos de código, que opcionalmente se puede ejecutar en un programa completamente funcional. Como es obvio, ningún framework es completamente funcional sin agregar ningún código por parte del programador.

Por lo tanto, la inversión de control es más una base sobre la que construir un elemento, es nuestra arquitectura de soporte, mientras que la base sobre la que se programa un plugin es un elemento completo y funcional que se extiende mediante el plugin, pero que no depende de él.

Este es otro de los grandes elementos en los que se basa la Ingeniería del Software al decir que, lo importante, es la lógica de negocio o el sistema en sí que se quiere desarrollar, dejando la parte de arquitectura de soporte y el trasfondo sobre el que se ejecuta la solución al framework.

Si aún se tiene alguna duda, puede que con este ejemplo se disipen (o aumenten ), tomado del artículo de Martin Fowler comentado antes, tenemos un trozo de código en Ruby tal que así:

puts '¿Cómo te llamas?'
nombre = gets
procesa_nombre(nombre)
 
puts '¿Qué buscas?'
busqueda = gets
procesa_busqueda(busqueda)

En este trozo de código todo está bajo control, el sistema se ejecuta de forma lineal, pide la información en el momento en el que se le ha escrito y descrito y el código se ejecuta, secuencialmente, de forma predecible.

Ahora veremos otro ejemplo:

require 'tk'
 
root = TkRoot.new
nombre_etiqueta = TkLabel.new() { text "¿Cómo te llamas?" }
nombre_etiqueta.pack
 
nombre = TkEntry.new(root).pack
nombre.bind("FocusOut") { procesa_nombre(nombre) }
 
busqueda_etiqueta = TkLabel.new() { text "¿Qué buscas?" }
busqueda_etiqueta.pack
 
busqueda = TkEntry.new(root).pack
busqueda.bind("FocusOut") { procesa_busqueda(busqueda) }
 
Tk.mainloop()

Aquí hay una gran diferencia en el flujo de ejecución, ya que los mensajes se ejecutan en el orden que el framework los llama, según la interacción del usuario. En este caso, el framework controla la ventana, los eventos que se suceden sobre los elementos gráficos y, en el caso de que haya un evento, si hemos desarrollado código para atender a ese evento, es el framework el que llama a nuestro código. Eso es inversión de control.

La verdad es que, en el momento que vi el fichero de Gemfile, queda clara la misión de dicho fichero, ya que viene con una colección básica de gemas que se suelen instalar de forma base cuando se trabaja con rails (out of the box) y unos comentarios de gemas que aconsejan para ciertos usos cotidianos (opcionales).

Indagando un poco, topé con su web, en la que viene cantidad de documentación sobre su uso y, ejecutando, simplemente, desde la consola:

bundle install

Me encuentro con que el sistema comienza a instalar rails y todos los paquetes base necesarios para poder tener el proyecto activo y funcionando sin problemas.

Esta es otra de las joyas que hacen que Ruby on Rails sea fácil de usar para el desarrollo rápido de aplicaciones web. Lo recomiendo, merece la pena.

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 ello, aprovecho para que, los que sigan interesados en el mundo del bussiness intelligence puedan ver más tipos de software, algunos de ellos mucho más avanzados de lo que cabría esperar:

• Pentaho Data Integration: es quizás el que mejor se mantiene de todos los software medio libres que existen en este ámbito. Las versiones más antiguas de Pentaho están abiertas para la comunidad sin necesidad de pagar ninguna licencia, mientras que las nuevas versiones solo son de pago. No obstante, las herramientas propias de Pentaho para realizar las transformaciones han evolucionado de forma que son más flexibles, potentes y simples al mismo tiempo.
• Benetl: después de haberlo visto durante bastante tiempo, no sé si llamarlo concretamente ETL, ya que su misión específica consiste en la carga de ficheros de tipo txt, csv o xls, a una base de datos que, tan solo, puede ser PostgreSQL o MySQL. Esto hace que sea un sistema muy limitado, pero no obstante bueno si tus necesidades se adaptan a la tarea en concreto.
• Talend Open Studio: es un sistema que me ha convencido realmente, en cómo debe de ser un buen sistema ETL. Aparte de ser un sistema open source, es un sistema visual muy completo que no solo permite generar tareas ETL en Java (como hacen muchos), sino también en Perl. Tiene un vídeo de demostración el cuál aconsejo encarecidamente, ya que muestra ampliamente varios ejemplos de uso de la herramienta.

¿Conocéis más herramientas o incluso las profesionales que se usen en entornos bussiness intelligence?, ¿qué opnión os merecen? ¡echad un comentario!

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.