EspañaInglaterraAlemaniaItaliaPortugalFranciaEspañaInglaterraAlemaniaItaliaPortugalFrancia
Enseñar al mundo nociones de arquitectura, complejidad y formas de actuar

Presentación

Seguramente la gente no tiene claro lo que significa la palabra arquitectura unida a un proceso de desarrollo y despliegue ágil.

Intentaré resaltar la complejidad arquitectónica del modelo y hacer mención de todo lo que puede estar involucrado en una arquitectura de portales.

El producto elegido es Drupal, pero no es Drupal el centro de la arquitectura, sino un enclave en la misma.

Una buena arquitectura debe poder adaptarse a otro producto sin complejidad excesiva y manteniendo su base firme.

Vamos a describir todo lo que consideramos que es arquitectura. Para ello vamos a ir de la parte de sistemas avanzando hacia un desarrollo y terminando en una comunidad de portales.

Cinco Enclaves

g.- Enclaves arquitectónicos : La presentación y composición de dichos componentes también es arquitectura

Por defecto Drupal presenta los componentes en formato de lista.

A su vez nos proporciona Bloques , Vistas y otros objetos para poder desplegar la información en nuestros portales. La decisión de cómo hacer ese despliegue y la capacidad de modificarlo está relacionado con una adecuada arquitectura de presentación de contenidos.

Desde que existen estos productos, desde la época del Php Nuke y otros similares , se ha distinguido entre un formato reducido del componente, en Drupal conocido como Teaser, y un formato más ampliado donde se despliega todo su contenido, conocido como Body , Cuerpo , Full , Completo, etc.

De entrada disponemos de , al menos, tres variantes de presentación :

- Títulos

- Teasers

- Full

La idea es poder personalizar estos componentes acorde a la información que queremos mostrar en cada momento.

Drupal por defecto permite cortar por número de caracteres, incluso hay módulos que crean un campo aparte para los teasers.

Pero el módulo que nos da esa agilidad es Content Templates.

Este módulo nos permite personalizar la salida de nuestros componentes.

Este módulo permite crear sistemas de plantillas y como mejora aún, no se almacenan el BBDD, por tanto hablamos de componentes que pueden ser compartidos entre múltiples portales con los mismos tipos de usuario.

La decisión de cuando usar una plantilla o no es un factor trascendente de arquitectura.

A su vez los propios tipos de Drupal pueden relacionarse, tanto con enlaces como con inclusiones, es posible crear jerarquías complejas que conforman componentes más avanzados.

Esa composición, es un factor determinante de la arquitectura del portal.

Por tanto, la apariencia del portal no sólo se puede modelar con los propios objetos del mismo, sino también con los componentes creados por nuestra parte.

Considero que esta capacidad de crear componentes personalizados es una de las más poderosas facetas de Drupal.

El módulo de componentes y más aún la equiparidad entre campo y taxonomía aportada por otro fantástico módulo Content Taxonomy irán diréctamente en el núcleo de Drupal 7.

Es una prueba directa que nos informa de la importancia que tiene esta forma de desarrollar o de componer portales.

n.- Enclaves arquitectónicos : La capacidad para prevenir los cambios y la adaptación del sistema al futuro es arquitectura

Sin duda la vida de un site no debe considerarse hasta su creación, sino que más bien, ese debería ser el principio.

La capacidad de incrementar funcionalidad sin apenas coste adicional es una de las grandes bazas del software libre y por supuesto de la robustez de un producto como Drupal.

Por tanto cualesquiera nuevas funcionalidades aportadas por componentes ya utilizados pueden suponer un incremento de funcionalidad agradecida para la mayoría de portales que se están manteniendo.

Es por ello que un site no debe considerarse como un portal único, sino como todo un proyecto.

Un proyecto con vida, que dispone siempre de entornos paralelos.

En razón a esta funcionalidad disponemos de otras dos metodologías.

La primera es Live Backups - Copias de Seguridad Vivas.

Está enfocada en aportar esa sensación de continuidad a los sites, con capacidad de poder visualizar el futuro y el pasado.

Sensación de control absoluto de la evolución de los portales.

Disponemos a su vez de varios proyectos de control, el primero de ellos pretende gestionar todos los portales y dominios :

Control Arquitectura Portales - Brqx

El otro portal pretende auto comprobar el funcionamiento de todos los sites, con objeto de poder anticiparnos a los problemas.

Control Servidores y Sites - Brqx NG

Esta filosofía encaja perfectamente con la metodología 5 Entornos - Five Environments

Donde se puede comprobar la evolución y el estado de cualquiera de nuestros portales.

Son múltiples técnicas que permiten simplificar la gestión y optimizar el desarrollo, con finalidad absoluta en criterios de calidad y en un acercamiento a las necesidades reales de los clientes.

l.- Enclaves arquitectónicos : La necesidad de conocimiento de los componentes disponibles es arquitectura

Otra de las características relevantes del software libre es su gran capacidad de cambio, de mejora, de nuevas funcionalidades.

Es tan variante esta filosofía que en un periodo corto de tiempo una buena solución se queda obsoleta.

Por tanto es trascendente para un arquitecto en Drupal estar siempre al día de nuevos componentes, de su adaptación a las versiones.

Conocer perfectamente el Update Status y el Upgrade Status de sus portales.

Anticiparse a los problemas y cuando hay que actuar, estar preparado para ello. Es importante probar nuevas funciones, probar contribuciones para el producto, informarse de las ventajas aportadas.

Examinar comparaciones de productos, analizar las funcionalidades nuevas aportadas para ser capaz de decidir si esa novedad es trascendente para una mejora del portal o simplemente es un código ampliado que no aporta nueva funcionalidad.

Drupal tiene más de 5000 módulos, actualmente 4 versiones en danza, más de 500 contribuciones, multitud de información. Todo ello hace al producto completo y complejo.

Hay mil variantes y muchas formas distintas de hacer las cosas, ninguna tiene que ser la mejor, excepto algunos casos excepcionales.

Por tanto una buena arquitectura de Drupal debe concebir ese esfuerzo continuo en investigación de nuevos componentes y nuevas versiones para componentes existentes.

a.- Enclaves arquitectónicos : La definición de la estructura del producto es arquitectura

Las primeras veces que te acercas a Drupal, no consideras su estructura como un enclave importantísimo para poder gestionar múltiples portales.

Los propios creadores de Drupal incluso empiezan a orientarnos de las posibilidades y de la importancia de una buena arquitectura de ficheros.

El ver que es un grave error meter todo en "modules". La oportunidad de clasificar en "sites/all/modules" distintos enfoques y distintas agrupaciones de módulos.

Esa capacidad para discernir las necesidades comunes de las opciones específicas para uno u otro portal es arquitectura.

Es importante hacer un enfoque adecuado de los portales que queremos desplegar y es trascendente entender el enfoque libre y recomendado por Drupal, donde en vez de buscar una guerra individual, se apuesta por una compartición de conocimientos y responsabilidades en el desarrollo.

Lo que hemos denominado Metodologías Ágiles Colaborativas, donde tu éxito depende del éxito de otras empresas y retunda en el completo éxito del producto.

Siguiendo esta filosofía, la gestión de portales no debería ser un control de versiones, pues ya el propio producto dispone de su propio control de versiones.

Los cambios o mejoras deberían hacerse en consonancia y acuerdo con los propios responsables de esos módulos o temas. Es esta idea la que nos infunde Drupal, y además es la más adecuada para asegurar los criterios de calidad del software.

Por tanto podemos ver como estructura ideal una gestión de portales que no tiene por qué ser gestión de versiones.

En esta estructura tenemos una parte relacionada directamente con el producto como son las carpetas :

-"includes"

-"scripts"

-"profiles"

-"modules"

-"misc"

-"themes"

La misma podría ser una serie de "links simbólicos" que apuntan a la versión más moderna y estable del producto.

Por tanto delegamos parcialmente en files y de manera más general en sites la personalización del producto.

Dentro de files podemos plantear una estructura común con personalizaciones para documentos como iconos, logos e imágenes :

/files/

Esta ruta se puede parametrizar para conseguir un acoplamiento más optimo de componentes comunes.

En la otra linea, en sites tenemos la siguiente estructura ya aportada por Drupal

/sites/all/ --> Para todos los portales

/sites/default/ --> Configuración por defecto

Como bien dije esta estructura incrementa la complejidad del portal y no nos permite hacer un enfoque de simplicidad.

En dicha estructura tendríamos, por ejemplo tres sites :

sites/site1

sites/site2

sites/site2

sites/all

sites/default

Como se puede comprobar todo está dentro del mismo sites.

Nosotros preferimos ver el producto de forma más sencilla, donde toda la estructura siempre sea similar sea cual sea el site y donde los cambios de entorno sean totalmente transparentes a la estructura interna:

En nuestra visión tendremos :

sites/default --> Sólo configuración

sites/all --> Componentes comunes y personalizados

Esta estructura será común en todos los portales.

i.- Enclaves arquitectónicos : La relación entre componentes comunes para los portales es arquitectura

¿ Cómo conseguir una batería de portales ? ¿ Realmente creen que de un portal a otro hay tantas diferencias ?

La realidad es que no, sus similitudes rara vez bajan del 90% de los componentes comunes utilizados.

Por ello, la necesidad de preparar una arquitectura de componentes que permita una fácil re utilización.

Esta arquitectura requiere un completo sistema documental, para facilitar su identificación y diagnosticar de forma más adecuada la satisfacción de requisitos.

Estas relaciones se deben hacer por funcionalidad común.

Drupal nos facilita la labor, pues ya propone su propio sistema de relaciones entre módulos, pero nosotros debemos continuar esa misma labor organizando otros muchos componentes que vamos creando.

Para sentar una base inicial, indicaremos la subdivisión propuesta por Drupal.

Se ha especificado una lista de las funcionalidades más comunes en la mayoría de los portales :

- Autenticación

- Presentación de contenidos

- Comunidades

- Gestión de Usuarios

- Correo - Listas - Foros

- Publicidad - PopUps

- Localización

- Búsquedas

- Sindicación

La propia comunidad Drupal estructura aún así sus módulos en una serie completa de funcionalidades que se suman a las más comunes. Se indican a continuación:

- Utilidades

- Gestión de contenido

- Administración

- Tipos de contenido

- Desarrollo

- Comunidad

- Media

- E-Commerce

- Filtros - Formato de entrada

- Vistas

- Categorías

- Movilidad

- Utilidades Javascript

- Navegación

- Gestión de Ficheros

- Backups - Importación - Exportación

- Paginación

- Seguridad

- Prevención de Spam

- Evaluación - votaciones

- Localización - Idiomas

- Grupos Orgánicos

- Estadísticas

- Eventos y Workflows

- Rendimiento

- Juegos

- RDF - Formatos

- Gestión de Rutas

Es una base para poder organizar una estructura de componentes consistente y con una sencilla re utilización.

Arquitecto Ricardo Cabello Torres

Estoy a disposición laboral para trabajar como Arquitecto Metodologías Ágiles Drupal o bien ofrecer mis servicios de diseño de portales en Portales Profesionales.

Invito a que conozcan a su vez un enfoque revolucionario de posicionamiento basado en arquitectura : El mejor posicionamiento - Brqx

Es un placer compartir con ustedes mis inquietudes en la sociedad y mi lucha unánime por un mundo mejor. Les invito a conocer Costumbres Sociales Actuales - Brqx.

También si les gusta el coleccionismo de calidad, les invito a participar en proyectos como Mis Palillos o Mis presentaciones.

Sin otro particular, gracias por tu visita.

Facetas de Drupal - Enclaves del Éxito

a.- Enclaves arquitectónicos : La definición de la estructura del producto es arquitectura
b.- Enclaves arquitectónicos : La relación con otros productos que permitan un mejor despliegue es arquitectura
c.- Enclaves arquitectónicos : La correcta definición de necesidades a nivel de sistema es arquitectura
d.- Enclaves arquitectónicos : La interrelación entre distintos sistemas es arquitectura.
e.- Enclaves arquitectónicos : La elección de los componentes es arquitectura
f.- Enclaves arquitectónicos : La definición de los nombres de los componentes es arquitectura
g.- Enclaves arquitectónicos : La presentación y composición de dichos componentes también es arquitectura
h.- Enclaves arquitectónicos : La categorización de la ruta de los componentes es arquitectura
i.- Enclaves arquitectónicos : La relación entre componentes comunes para los portales es arquitectura
j.- Enclaves arquitectónicos : La decisión de reutilización de componentes es arquitectura
k.- Enclaves arquitectónicos : La gestión de los componentes y el control de los portales es arquitectura
l.- Enclaves arquitectónicos : La necesidad de conocimiento de los componentes disponibles es arquitectura
m.- Enclaves arquitectónicos : Los parámetros de usabilidad y seguridad aplicados a los componentes elegidos son arquitectura
n.- Enclaves arquitectónicos : La capacidad para prevenir los cambios y la adaptación del sistema al futuro es arquitectura
o.- Enclaves arquitectónicos : La capacicidad de abstracción que permite interpretar un sistema complejo de forma simple, es arquitectura
p.- Enclaves arquitectónicos : La decisión de minimizar la documentación y agrupar las necesidades comunes es arquitectura
q.- Enclaves arquitectónicos : La relación de dichas necesidades con la de los componentes a utilizar es arquitectura
Distribuir contenido