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.

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.

Después de un recorrido por Symfony (PHP), Rails (Ruby) y Django (Python), he decidido echarle un vistazo a Catalyst (Perl) para ver qué novedades integra y en qué mejora, tanto a nivel de rendimiento, como a nivel de desarrollo, la generación de sitios web dinámicos.

Perspectiva MVC

Cada entorno integra MVC de una forma diferente, incluso lo que se entiende por MVC, desde los primeros libros a finales de los 70 y principios de los 80, es un esquema en el que la Vista puede interactuar con el modelo, al igual que el controlador con la vista y con el modelo.

En Rails, se presenta el fat model, donde la codificación referente a base de datos se realiza en estos, y el flujo de la aplicación recae en los controladores, que deciden qué tipo de vista o presentación de la información emplear, dando facilidades para la presentación en HTML, JSON, XML… e incluso vía email.

En cambio, Django, no dispone de controlador como tal, ya que lo nombran por defecto como views, siendo esta la entidad que controla el flujo y la presentación, ayudada de la plantillas usando DTL. En este caso, la parte de MVC queda más difusa y ellos mismos explican en su web, que se podría decir más bien que Django es MTV (Model-Template-View).

Catalyst, sin embargo, tiene más semejanza a Rails en este sentido. Tiene un parte para los controladores, una parte para los modelos y otra parte para las vistas. Así mismo, las vistas se desarrollan, al igual que Django y Rails, con un sistema de plantillas (templates).

Al crear un proyecto, tan solo ejecutando el siguiente comando, se genera la estructura de ficheros que podemos ver a continuación:

$ catalyst.pl miproject
created "miproject"
created "miproject/script"
created "miproject/lib"
created "miproject/root"
created "miproject/root/static"
created "miproject/root/static/images"
[...]
$ tree
.
├── Changes
├── lib
│   ├── miproject
│   │   ├── Controller
│   │   │   └── Root.pm
│   │   ├── Model
│   │   └── View
│   └── miproject.pm
├── Makefile.PL
├── miproject.conf
├── miproject.psgi
├── README
├── root
│   ├── favicon.ico
│   └── static
│       └── images
│           ├── btn_120x50_built.png
│           ├── btn_120x50_built_shadow.png
│           ├── btn_120x50_powered.png
│           ├── btn_120x50_powered_shadow.png
│           ├── btn_88x31_built.png
│           ├── btn_88x31_built_shadow.png
│           ├── btn_88x31_powered.png
│           ├── btn_88x31_powered_shadow.png
│           └── catalyst_logo.png
├── script
│   ├── miproject_cgi.pl
│   ├── miproject_create.pl
│   ├── miproject_fastcgi.pl
│   ├── miproject_server.pl
│   └── miproject_test.pl
└── t
    ├── 01app.t
    ├── 02pod.t
    └── 03podcoverage.t

10 directories, 25 files

En el directorio lib/miproject es donde está el código principal.

Los controladores

A diferencia de otros entornos, las URLs o rutas para acceso a los métodos de Catalyst son implícitas a las subrutinas de cada paquete que está en el directorio (o paquete) de controladores. Por ejemplo, si editamos el fichero lib/miproject/Controller/Root.pm y agregamos el siguiente código:

sub libros :Global {
    my ($self, $c) = @_;
    $c->response->body ( "listado de libros!" );
}

Al ejecutar el servidor de pruebas: script/miproject_server.pl; podremos ver la siguiente tabla:

[debug] Loaded Private actions:
.----------------------+--------------------------------------+--------------.
| Private              | Class                                | Method       |
+----------------------+--------------------------------------+--------------+
| /default             | miproject::Controller::Root          | default      |
| /end                 | miproject::Controller::Root          | end          |
| /libros              | miproject::Controller::Root          | libros       |
| /index               | miproject::Controller::Root          | index        |
'----------------------+--------------------------------------+--------------'

Al cargar la página http://localhost:3000/libros podemos ver el resultado de la ejecución de la subrutina escrita.

La vista

Hemos realizado antes una salida directa desde el controlador, pero lo suyo es crear una vista. El sistema de plantillas de Perl se denomina TT. Es parecido al que se usa en JSP e incluso al que usa la DTL (Django Template Library), pero difiere bastante. Vamos a generar una vista primero:

$ script/miproject_create.pl view HTML TT

Con esto nuestro directorio de View se completa con la generación de un módulo de Perl HTML.pm. Ahora creamos una vista con la siguiente información en la ruta root con el nombre listado.tt:

<h1>Hola mundo!</h1>
 
<p>[% libros %]</p>

Para lo que habrá que cambiar la subrutina escrita anteriormente a la siguiente (también se puede cambiar el nombre y agregar como una completamente nueva):

sub libros :Global {
    my ($self, $c) = @_;
    $c->stash(template => "listado.tt");
    $c->stash(libros => "no hay libros");
}

Los modelos

Tanto Django como Rails, e incluso Doctrine, tienen sistemas de migraciones o sincronización con base de datos. Catalyst no dispone de estos mecanismos. Puede generar sus modelos de una conexión de base de datos con tablas ya creadas, pero no al contrario.

No obstante, su ORM es bastante potente. Por ejemplo, pongamos que creamos una base de datos SQLite (supongamos que en /tmp/libros.db):

PRAGMA foreign_keys = ON;
CREATE TABLE libros (
     id INTEGER PRIMARY KEY,
     titulo TEXT
);
 
CREATE TABLE autores (
     id INTEGER PRIMARY KEY,
     nombre TEXT,
     apellidos TEXT
);
 
CREATE TABLE libros_autores (
     libro_id INTEGER REFERENCES libros(id) ON DELETE CASCADE ON UPDATE CASCADE,
     autor_id INTEGER REFERENCES autores(id) ON DELETE CASCADE ON UPDATE CASCADE,
     PRIMARY KEY (libro_id, autor_id)
);
 
INSERT INTO libros VALUES (1, 'Diseño Ágil con TDD');
INSERT INTO libros VALUES (2, 'No me hagas pensar');
INSERT INTO libros VALUES (3, 'Hacking Etico');
INSERT INTO libros VALUES (4, 'Perl Best Practices');
 
INSERT INTO autores VALUES (1, 'Carlos', 'Ble');
INSERT INTO autores VALUES (2, 'Steve', 'Krug');
INSERT INTO autores VALUES (3, 'Carlos', 'Tori');
INSERT INTO autores VALUES (4, 'Damian', 'Conway');
 
INSERT INTO libros_autores VALUES (1, 1);
INSERT INTO libros_autores VALUES (2, 2);
INSERT INTO libros_autores VALUES (3, 3);
INSERT INTO libros_autores VALUES (4, 4);

Generamos nuestros modelos con el siguiente comando:

$ script/miproject_create.pl model  DB DBIC::Schema \
     MiProject::Schema create=static \
     dbi:SQLite:/tmp/libros.sqlite \
     on_connect_do="PRAGMA foreign_keys = ON"

Con esto nos genera un fichero de esquema en el directorio Model, con lo que tendremos el acceso a la base de datos configurada. Si quisieramos probar, tan solo necesitaríamos ejecutar lo siguiente. Modificamos la subrutina de nuevo:

sub libros :Global {
    my ($self, $c) = @_;
    $c->stash(template => "listado.tt");
    $c->stash(libros => [$c->model('DB::Libro')->all]);
}

Y también el fichero de plantilla por lo siguiente:

<h1>Hola mundo!</h1>
 
[% FOREACH libro IN libros -%]
[% tt_autores = []; tt_autores.push(autor.apellidos) FOREACH autor = libro.autores %]
<p>[% libro.titulo %] - [% tt_autores.join(', ') | html %]</p>
[% END -%]

Por último, agregamos las referencias necesarias en Libro.pm y Autore.pm (es lo malo del pluralize del inglés cuando se usan palabras castellanas):

__PACKAGE__->many_to_many(libros => 'libros_autores', 'libro');

Y esto para Autore.pm:

__PACKAGE__->many_to_many(autores => 'libros_autores', 'autor');

Con esto ya tendríamos un listado muy simple en funcionamiento. Puedes ver el tutorial completo (con un CRUD de ejemplo y más cosas aún) en la siguiente dirección (en inglés): Tutorial.

Conclusiones

El entorno proporciona las bases que proporcionan el resto de frameworks, su simpleza en las rutas y su formato de ORM hace que la programación de elementos sea bastante simple y rápida, no obstante, hay ciertos elementos con los que hay que tratar y revisarlos bien, leer bien la documentación y tratar de entenderlos, si no queremos toparnos con ningún problema a la hora de realizar cualquier entorno.

Personalmente, me ha gustado la experiencia y el entorno en sí, la programación con los módulos de Perl, lo documentado que queda todo si se siguen las líneas y el hecho de que no hace falta escribir mucho código para conseguir que el sistema funcione bien, hacen que sea un framework muy cómodo de utilizar.

En principio, si consideramos algo tan simple como el famoso heredoc, que en JavaScript no está soportado, en CoffeeScript es posible de la siguiente forma:

datos = '''
     Estimado lector,
 
     esta es una carta....
     '''

O algo típico como:

potencia = (x, y) ->
    a = 1
    for i in [1..y]
        a *= x
    a
 
alert potencia(5, 2)

Pero no es un nuevo lenguaje que vayan a soportar los navegadores, realmente es una abstracción que finalmente se traduce a JavaScript (ya sea por parte del servidor o del cliente a través de las librerías de javascript correspondientes) y se usa en el navegador. Eso sí, el lenguaje es más completo, ya que incluye cosas que JavaScript no tiene por defecto, y más claro, ya que usa la sintaxis de palabra sobre símbolo (equivalente al use english de Perl).

En la página web oficial de CoffeeScript podemos encontrar un manual extenso y lleno de ejemplos del lenguaje, con su equivalencia en JavaScript. La mayoría de trozos se notan más claros y escuetos en CoffeeScript. No obstante, es lógico que una persona que esté más habituada a leer y escribir código en JavaScript, lo que le costará es ver el acercamiento que intenta realizar este lenguaje.

La sintaxis recuerda un poco a YAML, y por ende a Python, ya que requiere de una indentación para identificar de que pende cada instrucción. Así mismo, en su carencia de la palabra clave return, se parece también un poco Ruby. El uso de las funciones se ha asemejado a las lambda que integran ahora muchos lenguajes (Java se espera que lo tenga para su versión 8 ) y que emplea la flecha o símbolo de conclusión lógica (que es también usado para la definición de funciones en Erlang).

Como buen lenguaje de scripting no requiere que se declare ninguna variable, a diferencia de algunas implementaciones de JavaScript, donde es requerido, sobretodo para fijar el alcance de la misma, y hace uso de las post-condiciones, tal y como se puede ver en Perl y Ruby, en trozos como:

dato = 5 if valor > 5 and valor < 10

Es una de las mejoras que se integran en Ruby 3.1, por lo que, se puede probar en ese mismo entorno, o instalándolo directamente o a través del sistema de NodeJS. El sistema contiene un compilador o traductor que toma el código fuente y lo transforma en las librerías JavaScript necesarias para la página web, por lo que no penaliza el rendimiento de la propia página en sí.

Decir que, en mi parecer, el hecho de que sea un lenguaje que se compila a otro da la buena fe y esperanza de que el código generado sea estándar para todos los navegadores, así como la facilidad de que la implementación del mismo parte de un solo sitio, de una sola definición muy trabajada por el autor. Seguiremos de cerca su evolución.

En principio, podemos decir que una de las grandes mejoras (para muchos), es que ya no trae por defecto prototype, sino que se han decantado por jQuery. No obstante, como todavía hay gente que considera el uso de prototype para sus desarrollos, pues lo que han hecho es que por defecto se instala jQuery, pero se puede indicar a través de una opción que se instale en su lugar prototype. Esto es gracias a que han extraído estas librerías a gemas independientes: prototype-rails y jquery-rails.

En segundo lugar, y siguiendo con el tema de la parte cliente, han integrado unos asset pipelines, que facilitan la generación de código CSS y JavaScript a través de elementos como CoffeeScript, Sass, Less… y todos ellos a través de Sprockets.

Con el uso de Ruby 1.9.2 (o Rubinius o JRuby en modo 1.9) y un servidor como Unicorn, podemos emplear otra de las nuevas características: HTTP Streaming. Esta característica permite la descarga de las imágenes, elementos CSS y JS, mientras se genera la vista del HTML.

Otra de las ventajas que sobresale en esta versión es el Identity Map. Esta característica de Rails, más en concreto de ActiveRecord, hace que cuando un objeto se rescata de la base de datos, si se solicita de nuevo el mismo objeto, no se solicite de nuevo, sino que se tome el que ya está recogido y en memoria. Esto lo hace solo para los objetos que se instancian en la petición en curso y que son eliminados de la caché cuando la petición finaliza.

El resto ya son mejoras menores, como:

• El uso de JSON en lugar de XML para el scaffold.
• La creación de helpers para la autenticación de HTTP Basic y Digest.
• El uso del método change en lugar de up y down en las migraciones, generando la marcha atrás el sistema de forma automática.
• El uso de up y down como métodos de objeto y no de clase.
• La posibilidad de crear serializadores de forma fácil (los de XML y JSON vienen por defecto).
• y muchas más…

Para más información, puedes leer la ficha de liberación completa (en inglés).

Realmente, Rails está avanzando mucho y desde que comencé a usarlo, hará ya tres años, lo he visto agregar cada vez más nueva tecnología y elementos que me han ayudado a aprender mucho sobre el desarrollo profesional de entornos web. Así da gusto.

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.

Un vistazo al lenguaje

En su página web, nada más acceder, se ve un cuadro con un código de algo más de 20 líneas completamente funcional y que resulta en… ¡un chat! Aquí el código:

type message = { author : string ; text : string }
 
@publish room = Network.cloud("room") : Network.network(message)
 
user_update(x : message) =
  line = <div class="line">
            <div class="user">{x.author}:</>
            <div class="message">{x.text}</>
         </>
  do Dom.transform([#conversation +<- line ])
  Dom.scroll_to_bottom(#conversation)
 
broadcast(author) =
   do Network.broadcast({~author text=Dom.get_value(#entry)}, room)
   Dom.clear_value(#entry)
 
start() =
   author = Random.string(8)
   <div id=#header><div id=#logo></></>
   <div id=#conversation onready={_ -> Network.add_callback(user_update, room)}></>
   <div id=#footer>
      <input id=#entry onnewline={_ -> broadcast(author)} />
      <div class="button" onclick={_ -> broadcast(author)}>Post</>
   </>
 
server = Server.one_page_bundle("Chat", [@static_resource_directory("resources")],
       ["resources/css.css"], start)

La sintaxis del lenguaje recuerda bastante a JavaScript, con tintes de programación funcional al estilo Prolog. Esto mezclado a que la sintaxis de XML en que se basa HTML puede incrustarse en el propio código, como si de instrucciones propias del lenguaje se tratasen, haciendo que la salida en este formato sea más limpia que en otros lenguajes de etiquetas como JSP, ASP o PHP.

Sin saber nada del lenguaje, choca ver el ejemplo, donde se instancian algunos objetos de red (en el ejemplo del chat) y se agregan líneas con una sintaxis de operadores que no se ven generalmente en otros lenguajes (como +<-).

Se define un tipo de datos que se mantiene por sesión de navegador, y la información entre el navegador y el servidor se va intercambiando entre código JavaScript y AJAX. Así mismo, se hace una comunicación broadcast, esto quiere decir que se envía el mensaje que le llega al sistema a todos los que tengan una sesión abierta de la aplicación.

Este tipo de facilidad hace que realizar un chat en la web, como se muestra en el ejemplo, sea muy sencillo, así como realizar juegos en red, en internet, e incluso aplicaciones de gestión que requieran de notificación de cuando se toca la ficha de un cliente o similar.

Las potencias del lenguaje

En los últimos tiempos he ido viendo que se hace más patente la necesidad de los programadores en desarrollar aplicaciones en un modelo de concurrencia óptimo y fácil. En este sentido, lenguajes como Erlang, Scala, Clojure, Haskell, y ahora Opa, se han hecho un hueco y compiten en un sector en el que el desarrollo se complica con el resto de lenguajes, y estos lo resuelven de una forma cómoda y elegante.

Opa no es un lenguaje de propósito general, sino que está orientado 100% a la web. En este entorno se desenvuelve con soltura y se pueden desarrollar entornos complejos de una forma compacta, clara y concisa.

Lo que en otros lenguajes llega a ser un dolor de cabeza, como es la notificación de eventos, compartir memoria entre varios procesos y mantener el flujo entre muchas sesiones diferentes hacia solo una aplicación, Opa lo resuelve con sus elementos base.

Consiguiendo popularidad

En su página web, en estos días, anuncian el Opa Developer Challange 2011, el cual es un concurso (o desafío) para desarrollar una aplicación en Opa, consiguiendo a cambio, en caso de ser ganador, un premio según el puesto en que se quede (MacBook Air, iPad 2 o Nintendo DS).

Estos concursos son un foco importante para desarrolladores ya que hay dos cosas bastante atrayentes. La primera, el premio en caso de resultar ganador o de las tres primeras posiciones. La segunda… la palabra “challange” (desafío), lo cual resulta muy atrayente a ciertos programadores (hackers), que se interesan por los desafíos y las nuevas tecnologías.

En todo caso, esto será sin duda un empujón para el lenguaje, con lo que, entre las aplicaciones que ya hay desarrolladas y las que genere el concurso, se generará un buen abanico para dar más y mejor nombre a este lenguaje.

La parte mala…

Una de las partes que Opa hace más hincapié, es que no tiene errores de XSS ni inyección de SQL, es decir, es seguro. El problema, es que no tiene errores de XSS porque no permite reflection, algo que se hace bastante útil a veces, ni el uso de una base de datos SQL.

El tema de tener que emplear el sistema NoSQL de base de datos que integra el sistema Opa, hace que muchos desarrollos sean impracticables en este sistema, ya que dependen de una base de datos que se requiere sea en un SGBD de un tipo específico.

Esto se suma a que no tiene tampoco, al menos aún, soporte de SOAP o XML-RPC, por lo que tampoco podría acceder a un Web Service externo para poder tomar esos datos. No obstante, sí tiene soporte REST como servidor y como cliente, por lo que, desarrollando un sistema externo en otro lenguaje con acceso tipo REST a base de datos, podría hacerse un puente al sistema gestor de base de datos. Aunque, claro, es más trabajo y dependencia de un sistema que esté programado y desarrollado en otro lenguaje.

El hecho de que el lenguaje genere un binario ejecutable, da la seguridad de que no se puede modificar ni inyectar código, ya que no es scripting, pero eso le quita también la versatilidad de poder actualizar el código sin necesidad de parar el sistema. Además de que el hecho de que se distribuya un binario (en caso de Windows, un .EXE) lo hace sensible a ser atacado por virus.

Conclusiones

Es un lenguaje interesante, y una arquitectura igualmente curiosa. Para los que somos además administradores de sistemas, esto no es muy atractivo, ya que cierra un poco las puertas ciñendo el crecimiento a montar un solo elemento en los servidores, encapsulado y poco configurable. No obstante, en aras de la sencillez y puesto el foco en el objetivo a conseguir, resulta bastante óptimo y atractivo.

En mi opinión, cuando solucionen el hecho de poder conectarse, aunque sea de forma ActiveRecord, ORM o SQL a una base de datos relacional, sin perder la base en la que se forjó la idea y el sistema de Opa, el sistema comenzará a ser mucho más usado en muchos más ámbitos.

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.

¿Qué es y qué hace Xdebug?

Xdebug es un módulo de PHP que se carga únicamente cuando se quiere trazar una ejecución de un código PHP (por ello no conviene, en ningún caso, cargarlo en producción, ya que puede cargar de por sí el sistema).

El módulo se encarga de almacenar información de cada llamada a función de PHP, junto con la marca horaria en la que se sucede para tener la traza exacta del curso de la ejecución del programa.

¿Cómo y dónde se obtiene esta información?

Cada traza es soltada dentro de un fichero llamado cachegrind.out. finalizado con el número del proceso en el que se ejecuta el intérprete de PHP.

Este archivo puede ser abierto desde algún programa como KCacheGrind (de KDE para GNU/Linux y Windows), así como WinCacheGrind, xdebugtoolkit y WebGrind. Así se muestra con KCacheGrind:

Como puede verse, los procesos se muestran de forma jerárquica en las llamadas a través de un árbol de llamadas, pudiendo poner la base en cualquier función inicial.

Además, permite ver el listado de las llamadas que han sido más usadas, y las que más demoran su ejecución. Lo cual viene muy bien para poder optimizar, no solo las funciones en sí, sino también la forma en la que se llaman.

Conclusión

Es una gran herramienta que no debería de faltar en todo programador PHP, ya que nos da información muy valiosa sobre la optimización con la que escribimos nuestro código y nos puede señalar faltas en el rendimiento que solo se verían demasiado tarde, en producción.