Prioridad lineal de los procesos de una aplicación web

Cuando estamos manteniendo una aplicación web suele ocurrir que el usuario final nos pide cambios que rompen el esquema inicial de la misma, es decir, se quieren saltar todas las reglas del diseño en el que nos habíamos “partido los cuernos” de forma que fuera todo fácilmente mantenible y estable asi como escalable.

En estos momentos tenemos dos opciones: cabrearnos mucho y quejarnos con el usuario para que lo haga a “nuestra manera o carretera”, o bien, mucho mejor, que la prioridad forme parte de todo este asunto.

Es ahora cuando decidimos que la segunda opción favorece nuestro trabajo de forma que podemos ir todavía más un paso adelante, es decir, si después de realizar todas las tareas necesarias para generar una página de una aplicación el contenido generado requiere un cambio de última hora, podemos utilizar una prioridad para construir/destruir dicho contenido. Un ejemplo es utilizar CSS, la prioridad se establece con la opción “!important” ,entonces, si en el HTML de nuestro primer diseño de la web tenemos un listado de hoteles y necesitamos que en uno de los hoteles del listado se muestre una división de forma distinta, simplemente vamos a permitir que en el editor HTML WYSYWYG se puedan introducir etiquetas de estilo: <style> [ extended_valid_elements: “style” en tinymce ]y ahora vamos a reescribir la regla donde se necesita que se muestre de otra forma el contenido, en lugar de cambiar toda la lógica de la programación, entonces ,usando “!important” al lado de las reglas, por ejemplo para el ancho :

<style> #midivision { width: 350px !important;} </style>

de esa forma le damos prioridad a esta regla, lo mismo se puede hacer con javascript y el argumento “defer” de la etiqueta <script>, y lo mismo se puede utilizar en PHP si especificamos el orden de carga de las clases, etc etc.

Sistemas de etiquetas cíclicos para la web: buena idea, difícil implementación

La idea es crear una navegación única para cada usuario con la que vamos “barriendo” la web, usando los tags como cepillo: arrastra el polvo del contenido y nos quedamos con lo que interesa,gracias a un sistema cíclico de etiquetas clasificadoras.

Un sistema de etiquetas cíclico se basa en un sistema de etiquetas simple donde se dispone de una lista de n reglas de etiquetas (tags, cada una de una forma especial) que se aplican en un sistema de orden secuencial y después empiezan de nuevo por la primera regla.
En un sistema de este tipo, cada conjunto de reglas de etiquetas tiene una estructura especial donde es asociado un patrón a un usuario sólo si el primer elemento no es requerido, i.e., es independente del conjunto, entonces es borrado.

El lado oscuro del sistema

Sin embargo no todo es un camino de rosas, como suele pasar en los sistemas, se producen muchos problemas por el mal diseño del software y una pésima implementación puede hacer que un servidor web incluso se colapse…

Por ejemplo technorati usa un sistema de tags con 467 mil tags diferentes,cuando un típico diccionario puede tener alrededor de 75 mil entradas…la diferencia es impresionante, teniendo en cuenta que no todos los usuarios están utilizando realmente tags para clasificar sus artículos.

La parte oscura del sistema viene dado por los “memes”: si uso una cita o etiequeta específica en un artículo de mi blog o web, entonces, se conectará con otros artículos incluso de otros sitios, se crean vínculos…

Pero…sorpresa sorpresa!!, esto no funciona tan bien como se espera porque acabas creando subcomunidades que se estandarizan, pero que están navegando en contra de la dirección de otras subcomunidades.

Soluciones: usuarios y desarrolladores

En esta situación, ¿cuál de los dos grupos van a cambiar sus etiquetas retroactivamente?, o ¿es la persona que está navegando a través del sistema de etiquetas a partir de una serie de artículos la que debería saber acerca de esto y salirse del anillo a voluntad?

Con casi medio millón de etiquetas en una comunidad a la que le encanta progresar, quizás deberíamos replantearnos estas ideas y rediseñar nuestras aplicaciones…

Y ,pronto…¡la implementación!

Comprobando la regla 90/10 en PHP

¿90/10?

Este post es para iniciar el estudio de comprobación de si, realmente se cumple el que una aplicación escrita en PHP siga la regla 90/10 del software, la cual nos dice que un programa pasa el 90% de su tiempo de ejecución en tan sólo un 10% de su código.

Tomando los resultados de un “profiler” PHP y analizadolos podemos ver dónde “vive” el código de nuestra aplicación y de este modo realizar las optimizaciones necesarias…Basándonos en el pasado reciente de un script, podemos predecir con una predicción razonable qué instrucciones y datos utilizará en un futuro próximo, para ello podemos usar la caché de la clase zen_cache ,el sistema de memoria de System V con las llamadas de PHP, guardar datos de consultas en una sesión, etc.

Recordemos que existen dos tipos de localidad
LOCALIDAD ESPACIAL
d(t) + k = d(t+n) con n y k pequeños
“Si se referencia un elemento, los elementos cercanos a él tenderán a ser referenciados pronto”.
Es decir, si estamos accediendo a un array, seguramente volvamos a acceder pronto a él, no tiene sentido hacer un array muy grande, deberíamos optimizar el código para no usar arrays más grandes que uno bidimensional…

“Las direcciones de memoria que se están utilizando suelen ser contiguas”.
Por eso, es mejor utilizar
JUSTIFICACIÓN: Los datos relacionados se almacenan juntos.
Las instrucciones se ejecutan secuencialmente. k = n = 1
LOCALIDAD TEMPORAL
d(t) = d(τ+n) con n pequeño
“Si se referencia un elemento, tenderá a ser referenciados pronto”.
“La información que se usará en un futuro próximo es aproximadamente la misma que se está usando actualmente”.

Para diseñar un sistema óptimo se realizan todas las posibles configuraciones en ficheros .XML que definan el comportamiento para cada parte independientemente, por ejemplo, si quiero disponer de un modelo de datos de noticias con una caché que se actualice sólo, creando un fichero .XML y a la hora de usar el zen_generador, para obtener nuestra aplicación de noticias, añadiré una propiedad para que se inserte una clase zen_cache y su configuración es:

  • que se actualice siempre que se añada/modifique/borre una noticia (o se fuerce a ello)
  • que genere los listados de noticias automáticamente y los guarde en un fichero .HTML que es mucho más rápido que generar todos los listados cada vez que se cargue el script de noticias…
  • que disponga de un administrador con soporte AJAX y un cliente básico
  • que use el tema por defecto de zenphp para mostrar la información de los modelos…

Bueno,resumidamente, es lo que estoy haciendo en estos momentos…

Grafos multietapa en zenphp

Cómo ..¿grafos multietapa?…¿eso qué es y para qué sirve?
pues resulta que en un grafo multietapa sólo se puede llegar a un punto “etapa” desde una etapa anterior, y sólo se puede ir a una etapa posterior…hasta ahí bien…pero en la fase final convergen varias líneas!
Repasemos ésta cosa de los estados de una aplicación multiusuario y echemos mano de la memoria…a ver a qué me suena?,ah si!…el carro de la compra!…bueno…y transacciones, reservas de vuelo, etc. etc.

Al final resulta ser un problema de minimización…en principio, pero claro, quién nos iba a decir que un problema de Programación Dinámica es rentable en una aplicación de servidor,…que necesita, precisamente , descargar la CPU a toda costa…entonces, ésto requiere una reflexión más profunda, dado que no podemos sobrecargar un servidor con cálculos debe existir una solución intermedia para realizar las conexiones entre ,pongamos un ejemplo: unidades y productos…una conexión es una asignación con máximo beneficio…¿y qué es el beneficio en una aplicación tipo web?, ésta elección amigos, puede ser la solución al problema…ya que la matriz que vamos a construir puede llegar a ser muy grande, lo más probable es que desechemos el problema una vez que concluimos la solución…pero, ¿por qué no es factible? pensándolo bien, realmente no necesitamos llegar a analizar el problema completo…es decir, podemos cortar el proceso en un punto de la resolución si el tiempo que está llevando a cabo es demasiado y aplicar otro algoritmo con peor solución pero mejor tiempo medio…o…podemos calcular las mejores soluciones de los subproblemas y utilizarlas para procesar las peticiones del cliente al servidor…es decir, realizar las mejores asignaciones por lotes.
Casos de uso: procesamiento de aplicaciones que necesiten comprobar el estado de semáforo 🙂
Veamos una implementación

Continue reading