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

h.- Enclaves arquitectónicos : La categorización de la ruta de los componentes es arquitectura

La informática es una rueda que rara vez deja de ser redonda, sino que se disfraza con múltiples capas.

Durante años se ha identificado los componentes por una ruta específica, así pues en múltiples sistemas se han organizado niveles jerárquicos para organizarlos.

Esos mismos niveles indicaban una forma inequívoca de localizar un componente, como puede ser por ejemplo el fichero host en un sistema windows localizado en :

\System32\Drivers\Etc

Cada uno de estos parámetros aportaba valor y permite organizar el sistema.

También suponía una forma de localizar dicho archivo.

Buscando sistemas algo más potentes, podemos conseguir con enlaces simbólicos tanto en Unix como en particiones NTFS de windows distintos formas de acceder a dicho archivo.

Esa estructura tan estricta desaparece con el formato de BBDD, donde para localizar el contenido ya no es tan importante la ruta, sino más bien los campos por los que se busque.

Veamos un ejemplo :

/tierra/animales/domesticos/perro/caniche

Su categorizacion sería :

Planeta / Ser Vivo / Tipo Animal / Animal Domestico / Tipo Perro

Haciendo una query con estos vocablos sin duda accedemos al contenido, por tanto ya no es tan importante la ruta.

Pero tal como adelanté, volvemos a la misma rueda cuando lo que usamos es una URL.

Vuelve a ser importante la ruta.

Incluso con un sistema de meta tags, acaba siendo trascendente la ruta de los contenidos.

Hace un tiempo tenía un sueño, poder categorizar las rutas en razón a meta tags.

Les invito a ver lo que pedía en su día.

Brqx dream: Traceabilidad documental automatizada por taxonomías

Hoy en día esto ya es posible.

Y es más importante aún que esta idea ya irá directamente en el núcleo de Drupal en se versión 7.

Toda esa información categorizada nos permite llevar un control de los componentes de nuestro site, y a su vez aportar un valor documental extraordinario con objeto de fomentar políticas de posicionamiento.

Si, la capacidad de tracear rutas unida a la funcionalidad de abstracción de contenidos similares propia de Drupal con mod_rewrite incrementa notoriamente el valor documental de nuestro site.

Estos parámetros de traceabilidad ya fueron declarados y explicados en uno de mis primeros portales:

Idea Traceabilidad - Brqx

Sin duda ha sido una de mis obsesiones y de mis mejores aportes de arquitectura a todos y cada uno de los portales implementados.

Por tanto definir adecuadamente la ruta y el nombre de los contenidos con módulos como pathauto , token y auto_nodetitle es una labor de gran importancia para cualquier planteamiento arquitectónico con Drupal.

p.- Enclaves arquitectónicos : La decisión de minimizar la documentación y agrupar las necesidades comunes es arquitectura

¿ Cómo se puede minimizar la documentación ? De qué manera podemos acercarnos más a los problemas de forma que los documentos sean ágiles y sencillos de interpretar.

Debemos simplificar el sistema. Debemos olvidarnos de todos las metodologías como Uml u otras que lo único que han conseguido es complicar su representación y acercarla al programador o ni eso, sino enfatizar la necesidad de un puesto intermedio que las interprete.

Demos simplicidad al asunto, apostemos por un nuevo aire en un sistema sencillo de componentes.

Esta metodología ha sido una de las partes de la arquitectura defendida ante la entidad independiente Red.es perteneciente al Ministerio de Industria de España.

Les presento un sistema de documentación fuera de lo normal :

Metodologías ágiles - Sistema de documentación

Hemos conseguido desligarnos de documentar todos los componentes, auto asociamos requisitos a componentes y nos centramos exclusivamente en el negocio del cliente.

Simplificamos el modelo. Y esta simplificación es arquitectura.

m.- Enclaves arquitectónicos : Los parámetros de usabilidad y seguridad aplicados a los componentes elegidos son arquitectura

Hablamos de usabilidad como conjunto de técnicas que simplifican el manejo de una web y la acercan a las necesidades de los usuarios o clientes.

La capacidad para encapsular un producto como Drupal en un conjunto de abstracciones que simplifiquen el modelo ya acerquen el resultado al negocio del cliente es arquitectura.

Por defecto, un usuario jamás debería adivinar que es Drupal el producto que hay tras su site.

Por tanto es importante gestionar adecuadamente los roles del portal y asignar visibilidad en razón de las necesidades de cada rol.

Consideramos necesarios los siguientes 4 roles :

- Administrador : Conocedor de Drupal. Tiene permiso para hacer cualquier acción en el portal.

- Supervisor : Conocedor del Negocio. Debe poder realizar cualesquiera acciones que manejen el negocio. No necesita tener conocimiento alguno de Drupal.

- Usuario autenticado : Permiso para modificar , insertar y eliminar algunas facetas del negocio

- Usuario anónimo : Cualquier visitante del portal

Estos roles se podrán incrementar en razón de las necesidades del site.

El papel de cada rol juega un factor determinante en la seguridad del site.

El administrador deberá constatar todos los nuevos parches de seguridad que se puedan aplicar con objeto de intentar que las medidas de seguridad aplicadas sean las adecuadas.

El arquitecto del sistema debe definir adecuadamente las acciones a realizar en razón del rol de cada acción , cerciorándose de respetar criterios de privacidad del negocio.

En razón a la usabilidad, en Brqx Group, disponemos de dos metodologías de diseño aplicables :

Light Potals - Portales ligeros

El objetivo de dicha metodología es minimizar las opciones disponibles ajustándolas a las necesarias.

A su vez aplicamos la metodología Liquid Potals - Portales ágiles

Su fundamento es disponer de la máxima cantidad de información sin necesidad de usar scrolling de pantalla. La filosofía es que todas las acciones estén a vista del usuario, dar agilidad a los movimientos como si fuera un líquido.

Estas metodologías están a disposición de una adecuada arquitectura que desee apostar por la sencillez y la facilidad de manejo de un site.

A su vez un arquitecto debería intentar fomentar un sistema orto normal de forma que en todos los portales, los procedimientos de actuación sean similares.

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.

c.- Enclaves arquitectónicos : La correcta definición de necesidades a nivel de sistema es arquitectura

El producto en cuestión es bastante complejo, pero esa complejidad es un desafío continuo y una base constante de la capacidad del mismo.

Sin duda un producto sencillo, difícilmente puede ser un producto de calidad, pues a medida que se va incrementando el abanico de funcionalidades, va creciendo en igual medida su complejidad.

Es por ello que debemos considerar una buena elección de módulos, de componentes.

Es transcendental analizar las necesidades hardware para los portales, la memoria y la configuración de los sistemas. Los mecanismos de caché. Los módulos que puedan incrementar esa eficiencia.

Y por supuesto hacer un enfoque global considerando las necesidades actuales y el estado del arte del producto.

Si usamos una versión 5.x sabemos que no podemos usar una versión de php 5.3. Se ha comprobado inestabilidad con módulos como Content Templates. As su vez hay módulos que únicamente están para otra versión, otros que no mantienen continuidad.

Es importante hacer estudio continuo de todos los módulos y opcodes que requiere el producto.

A su vez es trascendente considerar que un sistema no es sólo Drupal.

Hay grandes avances para conseguir un sistema más eficiente tanto por parte de Acquia como por otras empresas como Chapter 3 que invitan a apostar por un sistema con Mercury.

Pero en ese sistema es muy complejo unirlo a un panel de control . De momento no hay instrucciones precisas para instalar Mercury con Whm/Cpanel, por tanto debemos considerar las necesidades del portal para plantearnos si realmente podemos usar Mercury entero o bien sólo Varnish, Memcached, Pressflow, etc. Es una prueba de que el estado del arte de estas tecnologías está continuamente cambiando, por tanto es muy importante tenerlo en cuanta para ajustar las necesidades del sistema a las configuraciones más adecuadas para el mismo.

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