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…

Dentro de toda la polémica que suscitó había gente que dudaba de uso durante las fases de desarrollo. Lo de siempre: Falta de tiempo, desconocimiento de uso, etc. Hacen que se le de muy poca importancia.

Mi experiencia me ha mostrado que el testing es una de las piedras angulares del desarrollo ágil actual porque afecta a todas las fases del desarrollo de un proyecto:
- Diseño: Con TDD (Test driven developement) se desarrollan los tests antes de implementar la funcionalidad. Esto nos define claramente como ha de funcionar dicho código. Nos ayuda a pararnos a definir el comportamiento externo de la pieza de código que vamos a escribir después del testeo.
- Codificación: Con el testeo en la mano podemos dedicarnos a refactorizar o pulir nuestro código hasta que se ejecute de una manera limpia y eficaz facilitando, entre otras cosas, la mantenibilidad del código entre otros desarrolladores.
- Integración en grupo: Si el proyecto se desarrolla en grupo nos es más fácil detectar aquellas cosas que estamos modificando en nuestro código y que afectan al resto. Nos facilita centrarnos en nuestra parte del código porque los testeos nos van a avisar qué espara el resto de desarrolladores de nuestra parte codificada y como se comporta el resto de las piezas de código no desarrolladas por nosotros.
- Evolución del proyecto: Este es un aspecto crítico del desarrollo ágil. Nuestro proyecto va evolucionando en iteraciones cortas y totalmente funcionales. En vez de hacer un megaproyecto para el cliente, evolucionamos poco a poco el proyecto en la dirección en la que éste dicta según va revisando el funcionamiento del mismo. En cada iteración el cliente va obteniendo una versión parcial del proyecto, pero totalmente funcional. Con esta filosofía, si metemos nuevas funcionalidades los testeos nos van a decir claramente cuales son las partes del proyecto que hay que modificar para incorporar lo nuevo, y lo que es evidente: Cuando lo hayamos hecho nos va a decir si todo vuelve a funcionar correctamente.

Bajo mi punto de vista el desarrollo bajo el paraguas del testeo me parece, no algo ineludible, sino totalmente incuestionable. De las tres patas del desarrollo ágil (junto con Integración continua y Pair programing) es la única no negociable en ningún tipo de proyecto.

Además no sirve para nada la típica excusa de que, como hay que “desarrollar el doble”, con la presión de tiempo es imposible hacer testing. Más bien se podría decir al contrario: A la larga se reduce drásticamente el tiempo total empleado en el proyecto. Lo malo es la frase con la que se empieza: “A la larga” y también que para hacer buen testing, como todo en la vida, hay que aprender.

Según nos comentó Obie Fernandez fuera de España el 90% de los desarrolladores de informática utiliza testing en el desarrollo de sus aplicaciones. Por lo visto en la pasada conferencia de Rails, en España, apenas se llegaba al 10%.

La idea es que tenemos una imágen almacenada en un servidor tal cual o embebida en una base de datos. Programamos un servicio que devuelva dicha imágen en formato Base64. No voy a entrar en como desarrollar este servicio, ya que dependerá de la tecnología utilizada: Rails, ASP.NET, PHP, Coldfusion, etc. Pero la idea es que dicho servicio cargue la foto desde la base de datos o desde el fichero físico y la codifique en Base64 para enviarla dentro de un XML al cliente Flex. Si os sirve de ayuda, nosotros lo hacemos así porque almacenamos la foto, tal cual en formato Base64, en un campo de tipo Text dentro de la base de datos. Este servicio, devolverá un XML similar al siguiente que, como se puede ver, es fácil diseñarlo para poder enviar varias fotos de golpe:

En Flex, tendremos un Command (programamos utilizando Cairngorm), que, apoyándose en un Bussiness Delgate, se descarga el XML en un objeto del ModelLocator accesible por la aplicación.

En el formulario de visualización de la foto, ponemos un campo imágen:

Y luego un script que permita interpretar el objeto XML descargado anteriormente para asignárselo al source de la imágen:

Resumiendo:
- Cargamos en un XML los datos del servicio.
- Llamamos a la funcion: loadImage, para que lea dicho XML y se lo asigne a un control de tipo: Image.

He desarrollado un proyecto que contiene un ejemplo completo de lo aquí expuesto: LoadImage.rar. Es importante leer el fichero README.TXT

Como mostrar un mensaje de alerta al pulsar en un enlace, con indicador de funcionamiento y llamando a un servicio web:

En el cliente (rhtml):

Loading…


En el servidor (rb):


def alert_without_rjs
render :text => "alert('Hello without RJS')",
:content_type => "text/javascript"
end


También se puede hacer renderizando una plantilla, con el mismo código rhtml:

En el servidor


def alert_without_rjs
end


Una plantilla: alert_without_rjs.rjs:


page.alert "Hello with RJS"


Me encontré el siguiente tutorial para implementar REST en Rails: Tutorial de desarrollo REST con Ruby on Rails

No está mal el sistema que utilizamos para comunicar los servicios web desarrollados con Rails y las aplicaciones cliente desarrolladas con Flex. Funciona bastante bien y con poca carga en la red, pero es poco flexible. Cualquier cambio supone un problema y esto va en contra de la naturaleza del desarrollo ágil. Esto es lo que me hace seguir investigando (y, bueno, que no tengo ganas de aburrirme).

Ahora estoy buscando la manera de integrar Flex con REST. Sería la manera más natural de utilizar los ValueObjects de Cairgorm. Los cuales hemos dejado de utilizar totalmente con nuestra manera de trabajar.
De todas formas, dentro de este camino de investigación constante en el que estoy sumido, deprime un poco ver enlaces como el siguiente: Flex can’t do REST. No pienso desfallecer.

Esto en cuanto al camino del desarrollo, pero también estoy siguiendo el camino de los sistemas. Ya he aprendido mucho de Linux, cuando me he topado con Xen. Aunque, también hay que tomárselo con cuidado.

Ruby On Rails:

Lo que más me está ayudando es correr la aplicación en un mongrel sobre Linux y ejecutar en una consola lo siguiente (cambiando RAILS_ROOT por el directorio donde esté la apliación:

tail -f {RAILS_ROOT}/log/devlopment.log

E incluir el siguiente código, cuando quiera notificar algo para verlo en el log:

logger.debug ( "Texto de depuración")

Esto me permite que, mientras estoy ejecutando la aplicación voy viendo, en tiempo real, el resultado de la ejecución de dicha aplicación.

Drupal

Drupal está desarrollado en PHP, por lo que cualquier técnica de depuración válida en PHP lo será para Drupal. Lo que ocurre es que hay una serie de herramientas muy útiles a la hora de depurar. La primera es un módulo denominado Devel, con él podremos ver fácilmente las llamadas a la base de datos, ciertos parámetros de los formularios, etc. Lo más interesante de este módulo es una función denominada: dpr. Es similar a print_r, con la ventaja de que formatea la salida, indentando los arrays, haciendo más fácil su lectura.

El otro grave inconveniente de la depuración de código de Drupal es el sistema de hooks para implementar llamadas. Este sistema permite implementar una función personal que será llamada en vez de la habitual del core de Drupal. Esto facilita mucho el adaptar Drupal a necesidades particulares en aquellos elementos que se quieran retocar, dejando el resto a su implementación por defecto.
El problema, es que las llamadas a funciones no tienen porque coincidir con el nombre de la función, siendo muy difícil, con una simple búsqueda al código, saber qué función llamó a cual otra. Para solventar este problema y saber cual es el proceso de llamadas hasta una determinada función, yo recomiendo utilizar la función PHP: debug_backtrace() que devuelve un Array con la información de las llamadas a funciones anteriores.
Esta función, unida a la anteriormente mencionada:

dpr(debug_backtrace());

Facilita mucho el seguimiento de ejecución de las funciones en Drupal.

El primero tiene copado el mercado de reproductores multimedia para navegadores web multiplataforma con Flash. Podría apostar a que hay más reproductores Flash instalados que ordenadores con sistema operativo Windows. También tiene controlado el mercado de los documentos electrónicos con el Acrobat.
El segundo, Google, esta reinventando el término de Sistema Operativo. Y su expansión de productos está siendo al revés de lo que en su día hizo Microsoft. No creo que quede mucho para que Google presente su S. O. propio. Eso si: corriendo en un navegador Web.

La estrategia de Microsoft para hacer frente a Adobe pasa por dos productos:

• Silverlight: Es un reproductor de aplicaciones RIA (Rich Internet Application) multiplataforma (bueno, Windows y Mac) y multinavegador. Convirtiéndose en el equivalente de Adobe Flash. Mientras que las aplicaciones Flash se programan con Flex, las de Silverlight se programarán con .NET.
• Metro: Es un formato para documentos electrónicos. En su momento dijeron que Vista incluiría un lector y que se podría crar contenido en este formato de manera gratuita.

Esto es una guerra continua. Parece que las empresas dominantes del sector se dedican exclusivamente a utilizar su poder para copiar lo que otros se han currado con imaginación y buen hacer. Y no lo digo por Microsoft solamente, en su tiempo Bill Gates se vio amenazado por el poder de IBM…