Nosotros montamos una versión personalizada de Drupal. Lo cual, siguiendo con la analogía Linux, lo podríamos considerar como una distribución propia de Drupal. En pocos minutos tenemos una web totalmente configurada y preparada con la funcionalidad establecida para que nuestro cliente se ponga manos a la obra, para él creamos un rol denominado administrador, de tal manera que introducimos un nuevo tipo de usuario entre medias. Él no accede a Drupal, accede directamente a un gestor de contenidos donde mantener y categorizar noticias, enlaces imágenes, etc… y usuarios! y aquí es donde aparece la discordia.

Un administrador de una de estas webs tiene que poder administrar usuarios y al administrar usuarios lo hace también del usuario root 8/. Por lo que puede, perfectamente, cambiarle la contraseña y acceder como él. Existen muchos comentarios sobre este asunto (Security: The “administer users” permission exposes user/1), pero para mí claramente es una brecha de seguridad. El usuario root debería de estar por encima de cualquier administrador y nadie (y menos un “simple” administrador de usuarios) debería de poder modificar sus datos.

Por otro lado, evidentemente, esto es software libre (nunca daremos suficientes gracias a la comunidad que hay detrás) y podemos modificarlo a nuestro gusto. No es que me guste modificar el core de Drupal, de hecho es una de las mejores características de Drupal: no es necesario tocar el núcleo para conseguir la funcionalidad buscada, basta con añadir los módulos necesarios. Pero en este caso no hay más remedio y, teniendo en cuenta que mi prioridad es modificar lo menos posible, implementé la siguiente modificación (modules/user/user.module):

< ?php
function user_save($account, $array = array(), $category = 'account') {
  global $user;
  if($account->uid==1 && $user->uid != 1) {
     drupal_set_message(t("Only root user can change its user information"), "error");
     return user_load($account->uid);
  }

  // Dynamically compose a SQL query:
  $user_fields = user_fields();
   ...
}

Reconozco que no es muy elegante, pero cumple su función: Por mucho que asigne administración de usuarios a cualquier usuario ninguno podrá acceder como root al sitio y, además modifico mínimamente el core de Drupal.

Por ejemplo, de manera muy sencilla, quiero testear un servicio que me devuelve una lista de registros de una tabla denominada ‘datos’ que contiene dos campos: ‘id’ y ‘nombre’. Si metemos dos registros el servicio REST de listarlos nos va a devolver un JSON como el siguiente:

[
{datos:{nombre:"Prueba1",id:"1"},
{datos:{nombre:"Prueba2",id:"2"},
]

No tiene mucho misterio, es un array con dos elementos. Pero lo que sí es sorprendente, si nos lo montamos bien, es lo claro que puede llegar a ser la definición de la feature de Cucumber:

	Scenario: Listing elements of type Datos
		Given a data with name "Prueba1"
		And a data with name "Prueba2"
		When I list "datos"
		Given the json reponse
			Then the json must contain "2" elements
			Given the "1" element of the json array
				Then the json element should contain the "datos" key
				Given the "datos" key of the json hash
					Then the json element should contain the keys: "id, nombre"
					And the json element should contain the key "id" with value "1"
					And the json element should contain the key "nombre" with value "Prueba1"
		Given the json reponse
			And the "2" element of the json array
				Then the json element should contain the "datos" key
				Given the "datos" key of the json hash
					Then the json element should contain the keys: "id, nombre"
					And the json element should contain the key "id" with value "2"
					And the json element should contain the key "nombre" with value "Prueba2"

Lo único que se puede advertir aquí es que no tiene mucho sentido testear los id’s ya que van a cambiar seguro de testeo a testeo, pero lo dejo como ejemplo de que se pueden testear más campos.
Como se ve queda un feature totalmente legible y que testea completamente el JSON devuelto.

La clave de todo esto está en los steps definidos para testear el JSON. De manera genérica un JSON contiene sólo arrays y hashes. Los primeros contienen elementos y los segundos claves de elementos. Los elementos a su vez pueden ser arrays o hashes también y así indefinidamente. Por lo tanto los pasos se reducen a:
- Seleccionar un elemento de un array o de un hash.
- Contar cuantos elementos tiene un array o un hash.
- Ver si un hash tiene una clave determinada.
- Ver el valor de la clave del hash.

Un ejemplo de dichos steps es el código siguiente:

Given /^the json reponse$/ do
  @json_sel_element = ActiveSupport::JSON.decode(@response.body)
end

Given /^the "([^"]*)" key of the json hash$/ do |key|
  @json_sel_element = @json_sel_element[key]
end

Then /^the json must contain "([^"]*)" elements$/ do |num_elements|
  @json_sel_element.size.should == num_elements.to_i
end

Given /^the "([^"]*)" element of the json array$/ do |num_element|
  @json_sel_element = @json_sel_element[num_element.to_i-1]
end

Then /^the json element should contain the "([^"]*)" key$/ do |key|
  @json_sel_element.keys.should include(key)
end

Then /^the json element should contain the key "([^"]*)" with value "([^"]*)"$/ do |key, value|
  @json_sel_element[key].should == value
end

Then /^the json element should contain the key "([^"]*)" with a null value$/ do |key|
  @json_sel_element[key].should be_nil
end

Then /^the json element should contain the key "([^"]*)" with a not null value$/ do |key|
  @json_sel_element[key].should_not be_nil
end

Then /^the json element should contain the keys: "([^"]*)"$/ do |keys|
  k = keys.split(",")
  k.each do |key|
    And %{the json element should contain the "#{key.strip}" key}
  end
end

Al final he escrito esto un poco rápido (me cuesta encontrar un hueco) lo remataré en breve. Pero para abrir boca no está nada mal…

Las Document-oriented Databases suponen un enfoque distinto de almacenamiento de datos al que proponen las tradicionales RDBMS (Relational Data Base Management System). No pretenden suplantar a éstas, sino más bien presentar una solución diferente a una serie de problemas comunes en el tratamiento de datos como puedan ser los cambios constantes de estructura, la tolerancia a fallos o la clusterización, por decir algunos.

Las diferencias básicas entre ambos tipos de bases de datos se pueden ver en la siguiente tabla (Obtenida de What_is_Couch):

SQL -> CouchDB
Esquema explícito predefinido -> Esquema implícito dinámico
Tablas de datos uniformes -> Coleccion de documentos con estructura variable
Normalizado. Los objetos se expanden en varias tablas. Dulicacioón reducida -> Desnormalizado. Los documentos se autocontienen. Los datos suelen estar duplicados.
Se debe de conocer el esquema antes de escribir o leer un objeto completo -> Solo es necesario conocer el nombre del documento.
Consultas dinámicas de esquemas estáticos -> Consultas estáticas de esquemas dinámicos.

Me ha gustado mucho el siguiente enlace: Is the Relational Database Doomed?. En él, el autor, expone los siguientes apuntes:
- Las bases de datos RDBMS han cumplido de manera eficaz las mayor parte de las necesidades de las aplicaciones. Simplicidad, seguridad, flexibilidad, rendimiento, escalabilidad y compatibilidad han sido sus vritudes generales, siendo algunas mejores en algunos puntos que en otros. Lo que ha ocurrido es que, a día de hoy, una de estas necesidades ha adquirido un protagonismo mucho más critico que el de todas las demás. Concretamente el de la escalabilidad.
- Los beneficios principales de una base de datos orientada a documento son los siguientes: Muy adecuado para funcionar en la nube y encaja de una manera más natural con el código.
- Por contra, los inconvenientes son los siguientes: El modelado del código no recae en la base de datos, sino en la aplicación (capa de negocios) y limitaciones en las consultas.
- Por último, recomienda usar estas bases de datos cuando: Los datos estén muy orientados a documento (obviamente), el entorno de desarrollo sea muy orientado a objetos, el almacen de datos sea “barato” y este bien integrado en el servicio de hosting y, por último, que la mayor preocupación se centre en ofrecer una aplicación altamente disponible y con gran velocidad de acceso a datos.

También es interesante la comparación de herramientas que realiza la siguiente entrada: Anti-RDBMS: A list of distributed key-value stores. Aparte de que la introducción es graciosa (pero con sustancia). Motivos por los cuales elegir una base de datos orientada a documento:
1. Sufres de Aplicación-en-la-nubemanía.
2. Necesitas una excusa para utilizar Erlang (Varias de estas DB’s están desarrolladas utilizando Erlang).
3. Has oido que CouchDB mola.
4. Odias MySQL y, aunque PostgreSQL está mucho mejor, no tiene ningún mecanismo de replicación decente y no hay posibilidad de comprar las licencias de Oracle.
5. Tus datos se almacenan y se obtienen, casi siempre, a través de su clave primaria y sin utilizar consultas complejas.
6. Tienes una cantidad de datos nada trivial y te da miedo manejar estructuras de RDBMS con sistemas de replicación y tolerancia a fallos.

Garcias a estas dos páginas y a alguna más, he encontrado la siguiente lista de bases de datos orientadas a documentos:

ThruDB
Project Volemort
MonetDB
Neptune
Redis
Tokyo Tyran + Tokyo Cabinet
HBase
Dynomite
Scalaris
Ringo
CouchDB
MongoDB
Cassandra

También ha bvisto otros sistemas de BD’s a tener en cuenta:
Virtuoso
Zope Object Database
Schemafree (MySQL Addon)
neo4j
Vertica
Drizzle

Como primer resúmen (dado desde la visión superficial que tengo actualmente) se podría decir que si las necesidades de la aplicación pasan por ser muy rápida y muy escalable (considerando si se va a trabajar con ingentes cantidades de registros) y si la estructura va a variar bastante a costa de necesitar una mayor inversión en desarrollo del modelo (aquí me gustaría incidir en que, si los testeos ya de por si son importantes, aquí lo son más aún) este tipo de bases de datos es una muy buena opción. Lo que esta claro es que cada tipo de base de datos tiene su lugar y hay que aprender a diferencia cuando conviene un tipo sobre otro.

A través de este blog y, siempre que el tiempo me lo permita, iré añadiendo datos sobre mis pesquisas sobre este mundo que está resurgiendo poco a poco y que es, cuando menos, bastante interesante.

Cuando creamos un módulo podemos hacer que atienda él mismo las peticiones que se harían al core si no estuviese. Dicho de otra manera: Nuestro módulo va a interceptar ciertas llamadas que se harían al core de Drupal para proporcionar un comportamiento diferente al de por defecto y no romper el sistema de enlaces propuesto por Drupal.

Por ejemplo, he desarrollado un modulo que muestra los elementos de una taxonomía de manera distinta a como lo hace Drupal. Para ello hemos redigido la llamada de menú: taxonomy/term/% (atendida por el core en el modulo Taxomony) a una función de nuestro módulo.

Al motor de enlaces le va a llegar dos entradas de menu que tienen la misma url, pero que apuntan a dos funciones distintas. Cómo hace Drupal para escoger la que va a atender? Pues muy sencillo, por el peso del módulo que atiende a las peticiones.

Todos los módulos se instalan con un peso por defecto, si a nuestro módulo le ponemos un peso mayor que el del módulo Taxonomy del core (la lista de llamadas se hace sobreescribiendo las anteriores y Drupal recorre los modulos, al generar el menú, de menor a mayor peso) la sobreescribirá con la entrada de menu de nuestro módulo.

Para cambiar el peso de un módulo, basta con actualizar el valor del campo weight de la table {system} de la base de datos de nuestro sitio. Para más información: How to update a module’s weight.

Por último recordar que el menú del sitio se encuentra cacheado en la base de datos. No basta con actualizar nuestro código para que queden disponibles los enlaces implementados en nuestro módulo. Hay que recargar la tabla {menu_links}. Esto es facil de hacer guardando la lista de módulos del sitio, sin tocar nada.

{4.0=>7, 3.0=>3, 6.0=>3, 9.0=>1, 7.0=>5, 10.0=>1, 5.0=>2, 2.0=>2, 8.0=>1}

Según la definición del calculo, deberíamos acumular, por un lado, la nota multiplicada por el número de alumnos que la han obtenido y por otro el número de alumnos totales que han cursado la asignatura.
Una manera estándar de hacer esto seria:


total_peso = hash.inject(0){|result, e| result += e[0]*e[1]}
total_alumnos = hash.inject(0){|result, e| result += e[1]}
media = total_peso/total_alumnos


Hay que reconocer que ruby tiene cosas muy interesantes y que, usadas con imaginación, pueden ayudarnos a mejorar mucho el código. Y una de ellas, que es la que comento aqui, es la posibilidad de multiplicar un array por un valor. Si a cada elemento del hash multiplicamos la nota convertida en array por el número de alumnos que han obtenido esa nota obtendremos un array con todas las notas de todos los alumnos. A partir de ahí basta aplicar el método avg del Array para que Ruby calcule la media. Esto es lo mismo que antes, pero reduciendo enormemente el código:


hash.map{|k,v| [k] * v}.flatten.avg


Todo parte de la necesidad de renderizar los Primary Links con una plantilla que no sea la estándar. Se puede renderizar con la plantilla links:

< ?php print theme('links', $primary_links ); ?>

O como menu_tree:

< ?php print menu_tree($menu_name = 'primary-links'); ?>

Y luego trabajar con el CSS, pero queremos ir un poco más allá: queremos definir exactamente el HTML que nos de la gana. Nuestra llamada va a ser:

< ?php print theme('primary_links', $primary_links ); ?>

Y, aparte, tener definido un fichero de plantilla: primary_links.tpl.php donde especificamos el comportamiento de la renderización del array de enlaces.

En Drupal 5 la manera de descubrir plantillas de temas es automática, nos hubiera bastado con tener algo de lo siguiente definido, por orden de importancia:
- Fichero de plantilla (primary_links.tpl.php) para que lo hubiera utilizado.
- Funcion propia de tema (nombretema_primary_links.tpl.php) dentro del template.php.
- Funcion propia del motor del tema (phptemplate_primary_links.tpl.php) dentro del template.php.

En Drupal 6 no es automático. Hay que indicárselo al motor, el cual cacheará las llamadas para hacer el proceso más eficiente.
Habría que implementar la funcion hook_theme dentro del tema (dentro de template.php) o dentro del módulo que necesite el template. Esta funcion debe devolver un array que defina como se comportan cada uno de los temas. Por ejemplo:

function nombretema_theme() {
return array(
'primary_links' => array(
'arguments' => array(
'links' => NULL
),
'template' => 'primary_links'
),
);
}


Hace básicamente lo que buscamos: Relacionar theme(hook, …) con el fichero: hook.tml.php.
Pero también podemos definir como queremos que se comporte ese hook, por ejemplo renderizando como una función del tema (comportamiento por defecto):


/**
* Implementation of hook_theme().
*/
function maristas_silvia_theme() {
return array(
'primary_links' => array(
'arguments' => array(
'links' => NULL
),
),
);
}

function nombretema_primary_links($links = array()) {
return "Renderizamos los enlaces primarios"; // Salida de ejemplo
}


En el ejemplo anterior la renderización encargada del hook la realizará una función del template.php.

Por nomenclatura se suele traducir los guiones bajos del nombre del hook (primary_links) a guiones simples al nombre del template asociado (primary-links.tpl.php).

Si se cambia la estructura de los hooks, hay que reiniciar la cache, esto se puede hacer con cualquiera de los siguientes métodos:
- En la página “Administer > Site configuration > Performance” hacer click en el botón: “Clear cached data”.
- Con el módulo devel, hacer clieck en el enlace: “Empty cache” link.
- Con la función: drupal_rebuild_theme_registry de la API.

Más información en:

- hook_theme : Drupal 6 API
- Theme guide (Drupal 6)

Esto, dentro de Cairngorm, puede hacerse en la función result del Comando (implementa la interfaz IResponder) que ha lanzado la petición. El problema de esta técnica estriba en que el comando, que es parte del Controlador, no conoce nada acerca de la Vista ni del Modelo. En realidad debería de poder acceder al Modelo, según el patrón MVC.

También se puede hacer utilizando observers que controlan cuando los datos pedidos han sido recibidos y por tanto se puede realizar la operación subsiguiente. Pero complica bastante el código y lo hace muy frágil.

Al final, estamos utilizando una técnica que parece bastante lógica y flexible y, gracias a Dios, es fácil de implementar. La inspiración ha venido a raíz del siguiente enlace: Cairngorm View Notifications.

Simplemente se basa en pasar al evento un parámetro adicional con la función que será llamada cuando el evento finalice.

La función result pasaría a ser algo así:


override public function result(event:Object) : void {
var eventR : ResultEvent = event as ResultEvent;
if (_event.function_result != null)
_event.function_result.call(this, eventR);
}


Me encantan las pequeñas ideas que ofrecen grandes soluciones.

Siguiendo en paralelo esta entrada hemos pasado por todos las arquitecturas posibles de aplicaciones Rails, bueno nos saltamos el FastCGI:

• Apache con mod_balancer
• Nginx con fair
• Mongrel
• Thin

Muchas, muchas horas invertidas con problemas de estabilidad, rendimiento, conexión a la base de datos defectuosa, etc, etc.
No hemos llegado todavia al paso de implementar HAProxy, aunque todo de andará. Pero con un nginx con fair, un stack de 10 thines y una buena máquina sirviendo el MySql, parece que nos hemos ganado un poco de tranquilidad.

Tenemos en plan crear dos máquinas virtualizadas con un stack de mongreles en cada una y el nginx que balancee a ambas. Esta arquitectura tiene que escalar hasta dos máquinas con cuatro stack de thines virtualizados cada una, lo que nos dará 80 thines dispuestos en paralelo, mejor balanceo de carga y una mayor tolerancia a fallos. Posiblemente tendremos que replicar la base de datos porque seguramente pasaremos el cuello de botella a ese extremo.

Por si sirven los siguientes datos, sacados de varios sitios web, entre ellos el de: Ezra Zygmuntowicz. Teniendo en cuenta:
- reqs: Request per second. Son el número de peticiones que se harán por segundo.
- tm: Tiempo medio de respuesta de cada petición.

El número de mongreles necesarios serán: reqs * tm. A su vez, se recomienda 8 mongreles por núcleo de CPU, con esto también nos permite obtener cuantos servidores necesitamos.
Por ejemplo: Si necesitamos servir 100 request por segundo y cada request toma una media de 0,5 segundos en ser enviada, necesitaríamos 50 mongreles. Una máquina QuadCore podría tener 32 mongreles, con lo que necesitaríamos 2 máquinas. Esto sin contar con el consumo de memoria RAM de la máquina. Si un mongrel consume unos 60Mb de RAM, para 32 mongreles necesitaríamos algo menos de 2Gb de RAM en la máquina.

Después de toda esta disquisición, voy a comentar en este y en sucesivos posts un nuevo chico en la ciudad (como se suele decir en inglés), se denomina: Phusion Passenger. Como todos los que comienzan promete todo: Gran velocidad, estabilidad, mucha documentación. Pero esta solución promete algo mejor y es virtual hosting de Rails con configuración cero.

Para desplegar un sitio Rails, aparte de saber programar ;), había que saber desplegar toda la arquitectura, vamos, lo que he comentado antes (nginx, mongreles, etc). Con modrail esto se acaba: Subes los ficheros de la aplicación Rails al directorio que atiende el virtual host y ya está funcionando.

He estado instalándolo en un servidor en el que tenemos varias aplicaciones Rails. La instalación ha sido bastante fácil: Una gema, un script de configuración y unas variables en el apache2.conf. Después de esto y, como por arte de magia, tenemos una aplicación rails corriendo en un virtual host sin tener que preouparnos por los mongreles ni por los balanceos de carga.

Cuando viene algo nuevo, suelo ser bastante excépctico. Todavía queda mucho camino por recorrer: A Ruby (Rubinius por ejemplo), a Rails y, en este caso, a modrails.

Por supuesto:
- Ruby on Rails
- Adobe Flex

Entran en la lista:
- Drupal. He montado un gran portal social sobre esta plataforma, lo que me ha dado una gran oportunidad para aprender y valorar sus grandes virtudes, que son muchas.
- Ext Js. . Mi fuerte no es el javascript, lo reconozco, pero esta librería permite desarrollar interfaces de usuario web muy potentes.
- Nginx. Un servidor web ruso, muy liviano y muy rápido.
- Thin. Un nuevo servidor de aplicaciones para Ruby on Rails, con bastante mejor respuesta que el Mongrel, pero con la estabilidad como duda.
- Memcached. Un servidor de cache en memoria.
- CAS. Una propuesta de Single Sign On.
- OpenID. Un nuevo sistema de autentificación web.
- Xen. Sistema de virtualización para sistemas Linux.
- Monit. Software de monitorización de servicios y recursos sobre Linux.
- AMF. Protocolo de intercambio de información entre un servidor y una aplicación ActionScript.
- Merb. Un framework de desarrollo web, similar a Rails, pero más orientado a rendimiento.
- Microsoft Sharepoint. Hay que reconocer que es el mejor software para Intranet disponible actualmente.

Fuera del trabajo:
- Mediatomb

Por ahora las listo, para que me sirva de una guía de temas de los que tengo ganas de hablar por si alguien puede estar interesado en escucharme…